Cisco IL5-Aware Purdue Architecture Reference Design

This draft expands the IL5-aware network reference model into a Cisco-centered architecture that keeps Purdue model separation, DoD authorization boundaries, supported Cisco reference designs, and practical post-quantum planning visible to the reader.

Cisco IL5-Aware Purdue Architecture Reference Design

This reference design expands the IL5-aware network model into a practical Cisco architecture for campus, data center, WAN, cloud access, OT, evidence, and recovery. The design is intentionally phrased as IL5-aware. Cisco hardware and software can help implement controls, segmentation, telemetry, and evidence, but the Mission Owner, Authorizing Official, Cloud Service Offering authorization, connection approval, RMF package, CSSP coverage, and operational evidence determine whether a real system can operate at DoD IL5.

The architecture uses the Purdue model as the organizing map. Purdue Levels 0-2 are kept close to control and process networks, Level 3 contains site operations and industrial data services, Level 3.5 becomes the industrial DMZ broker layer, Level 4 holds enterprise and campus services, and Level 5 represents approved mission enclave or DoD-authorized cloud service paths. The most important design rule is simple: do not route raw control traffic directly into enterprise or cloud networks. Broker, inspect, log, and approve every northbound path.

Design Intent

• Maximum flexibility: use VRFs, SD-Access virtual networks, TrustSec Security Group Tags, VXLAN EVPN, ACI tenants, firewall zones, and policy objects so the design can adapt without flattening the network.
• Supportable Cisco patterns: keep campus, WAN, data center, industrial security, Cyber Vision, and firewall placement aligned to Cisco reference design guidance instead of inventing a one-off topology.
• IL5 authorization support: produce boundary diagrams, route-control evidence, firewall rule evidence, identity evidence, flow telemetry, logging, vulnerability management, backup/restore evidence, and continuous monitoring artifacts.
• OT safety: use passive-first visibility, maintenance windows, plant-owner signoff, industrial DMZ brokers, and vendor access controls before enforcing new rules around control systems.
• Post-quantum readiness: inventory cryptography now, choose current Cisco platforms with crypto-agility and lifecycle runway, and test post-quantum-safe transport features in lab or approved pilot scopes.

Designing For IL5: Five-Layer Interactive Map

A useful IL5 design is not a single network diagram. It is a layered authorization story: define the boundary, prove identity, constrain network movement, control workload and cloud paths, then preserve evidence and recovery. The map below gives readers a clickable way to understand the five design layers and what should be included in each one.

IL5 Design Map: From Boundary To Evidence

Use this as a reader-friendly checklist. It does not replace the RMF package or AO decision, but it shows the five layers that must work together before a network design can credibly support IL5 operations.

Clickable Design LayersClick a layer to see what belongs there

Layer 11

Boundary And Governance

Defines what is being protected, who owns risk, and which cloud or connection scope is approved.

Includes: AO, RMF, CSO PA, CAP/BCAP/ICAP, PPSM.

Layer 22

Identity And Access

Turns access into an attributable decision tied to user, device, role, posture, and administrator workflow.

Includes: ISE, CAC/PIV, MFA, Duo Federal, PAM, TACACS+.

Layer 33

Segmentation And Inspection

Controls how traffic moves through enterprise, data center, OT, IDMZ, WAN, and approved cloud boundaries.

Includes: VRF, VN, SGT, ACI, EVPN/VXLAN, firewall, IDMZ.

Layer 44

Workload And Cloud Scope

Defines which mission services, OT data paths, cloud features, and partner interfaces are authorized.

Includes: apps, CSO services, OT brokers, DNS/NTP/PKI, backup.

Layer 55

Evidence And Recovery

Preserves the logs, telemetry, backups, restore tests, and monitoring artifacts that support ongoing authorization.

Includes: SIEM/SOAR, SNA, XDR/Splunk, Cyber Vision, ThousandEyes.

Important: these five layers are an architecture communication model for this article. The actual IL5 authorization still depends on the mission boundary, control implementation, inherited services, assessment, AO decision, and continuous monitoring evidence.

Cisco IL5-Aware Purdue Reference Architecture

A supportable Cisco fabric model that separates enterprise, data center, OT, IDMZ, CAP/cloud, evidence, and recovery paths. Hardware supports authorization evidence; it does not grant IL5 by itself.

Enterprise And Mission PathUser and mission traffic stays segmented and follows approved cloud routes.

Campus Access

C9350 access, C9550/C9610 core, CW917x Wi-Fi 7.

ISE, SGTs, MACsec, Catalyst Center.

Enterprise Data Center

Nexus 9000 fabric with VXLAN EVPN or ACI.

Secure Firewall, Secure Workload, Nexus Dashboard.

Approved CAP Path

BCAP, ICAP, or approved component connection.

DISN registration, PPSM, route evidence.

DoD-Authorized CSO

Only approved regions, services, and feature scope.

Cloud IAM, audit logs, evidence export.

OT And Purdue PathIndustrial traffic moves through brokered conduits, never direct enterprise-to-control routes.

Purdue Level 0-2

IE3400/IE3500 access, IE9300 aggregation, Cyber Vision sensors.

Cells, controllers, HMIs, engineering workstations.

Purdue Level 3

Industrial DC, historian, Cyber Vision Center, Secure Firewall 4200.

Site operations, patch staging, backup staging.

Purdue Level 3.5 IDMZ

Firewall, broker, jump/PAM, Secure Equipment Access.

Northbound telemetry and admin access are brokered here.

Software, Policy, And Control PlaneApplies across both enterprise and OT lanes.

Identity And Access

ISE 3.5, Duo Federal where authorized, PAM, TACACS+.

Automation And Fabric

Catalyst Center, Nexus Dashboard, APIC or NDFC.

Security Control

FMC/SCC where authorized, Secure Access, Secure Workload, Hypershield.

OT Visibility

Cyber Vision sensors and Center, Secure Equipment Access.

Evidence And Recovery PlaneReceives telemetry from every layer without becoming a bypass path.

Network Evidence

Secure Network Analytics, NetFlow/IPFIX, firewall events, route changes.

SOC Workflow

XDR/Splunk, Cyber Vision events, DNS/NTP/PKI logs.

Assurance

ThousandEyes path checks, Catalyst Center assurance, Nexus Dashboard.

Backup / Archive

Quantum DXi, ActiveScale, Scalar for recovery and evidence retention.

Diagram rule: arrows show logical sequence only. Software and evidence layers are cross-cutting services, not traffic shortcuts around segmentation or the IDMZ.

• Enterprise and cloud path
• OT/Purdue path
• IDMZ broker layer
• Software and evidence planes

Interactive Cisco Layer Explorer

The software side of the design is not separate from the network. ISE, Catalyst Center, Nexus Dashboard, APIC or NDFC, FMC or Security Cloud Control where authorized, Cyber Vision, Secure Access, Duo Federal, Secure Workload, Secure Network Analytics, XDR/Splunk, ThousandEyes, PAM, and backup platforms are the policy, control, visibility, evidence, and recovery layers that make the hardware design operational.

Enterprise And Mission Path

1

Campus AccessC9350, C9550/C9610, CW917xISE, Catalyst Center, Duo Federal

↓

2

Data Center FabricNexus 9000, Secure FirewallACI/APIC, NDFC, Secure Workload

↓

3

WAN / CAP EdgeCisco 8000, Catalyst 8300/8500SD-WAN, Secure Access where authorized

↓

4

Authorized CSOApproved cloud/services onlyCloud IAM, audit, SIEM export

Cross-Cutting Software Plane

S

Software / Policy / Control PlaneISE, Catalyst Center, Nexus Dashboard, APIC/NDFC, FMC/SCC, Cyber Vision, Secure Access, Duo Federal, Secure Workload, SNA, XDR/Splunk, ThousandEyes, PAM

OT, IDMZ, Evidence And Recovery Path

5

Purdue L0-2IE3400, IE3500, IE9300Cyber Vision sensing, passive first

↓

6

Purdue L3 OpsIndustrial DC and site servicesCyber Vision Center, historian, patch relay

↓

7

Industrial DMZFirewall, broker, jump/PAM, SEANo direct enterprise-to-control path

8

Evidence / RecoverySNA, XDR/Splunk, ThousandEyesQuantum DXi, ActiveScale, Scalar

Control Plane, Data Plane, And Evidence Plane

IL5-aware network design needs more than a clean physical diagram. The architecture should separate the data plane that carries user, workload, OT, and cloud traffic from the control and management plane that administers the network, and from the evidence plane that receives logs, flows, alerts, backups, and configuration records. Mixing those planes creates the same problem in a different costume: an attacker who compromises a user or monitoring system can pivot into the management or OT path.

• Data plane: user access, mission application traffic, historian replication, file transfer, API traffic, DNS, NTP, PKI, backup, and approved CAP/cloud paths. Each major data flow needs a source, destination, protocol, owner, inspection point, logging point, and rollback plan.
• Control plane: routing protocols, SD-Access control, ACI/APIC control, Nexus Dashboard, Catalyst Center, firewall management, ISE policy, Cyber Vision administration, and controller-to-device communications. These paths belong in dedicated management VRFs and administrator access zones.
• Evidence plane: syslog, NetFlow/IPFIX, firewall events, ISE session records, Cyber Vision events, XDR/Splunk correlation, backup job status, restore-test results, route changes, firewall changes, and cloud audit logs. Evidence receivers should not have unrestricted access back into production zones.

Purdue-To-Cisco Mapping

Purdue Layer	Primary Cisco Fit	Security Function	Evidence And Artifacts
Level 0/1: process, sensors, actuators, PLCs, RTUs, IEDs	Industrial Ethernet access where switching is needed; static policy for fragile assets; passive Cyber Vision sensing where supported.	Protect safety and deterministic operations. Do not apply enterprise scanning or patch cadence blindly.	Asset inventory, safety owner, passive protocol profile, known conduits, maintenance-window approvals.
Level 2: cell/area supervision	Cisco IE3400, IE3500, IE9300, local ACLs, VRFs, Cyber Vision sensors, optional ISE/TrustSec where platform and operations allow.	Separate production cells, HMIs, engineering workstations, local historians, and programming paths.	Cyber Vision inventory, cell-flow baseline, denied-flow tests, engineering workstation access records.
Level 3: site operations and industrial data center	IE9300 aggregation, Secure Firewall 4200 or virtual firewall, Cyber Vision Center, local historian, patch staging, backup staging, edge compute.	Control industrial data services before they reach enterprise or mission networks.	Historian replication logs, broker ACLs, firewall changes, Cyber Vision risk records, backup/restore tests.
Level 3.5: industrial DMZ	Secure Firewall 4200/6100 pairs where needed, FMC or Security Cloud Control where authorized, jump hosts, PAM, SEA, brokers, file transfer gateways.	Broker all northbound OT data and admin access. No direct enterprise-to-control route.	Firewall policy matrix, PAM/session recordings, broker topic ACLs, file transfer logs, isolation runbooks.
Level 4: enterprise IT and campus	C9350/C9550/C9610, Catalyst Center, SD-Access, ISE 3.5, TrustSec/SGTs, CW917x Wi-Fi 7, Secure Firewall, Secure Network Analytics.	Identity-based access, macrosegmentation, controlled admin access, flow visibility, and campus-to-data-center enforcement.	SGT matrix, VRF matrix, ISE session records, Catalyst Center inventory, config drift, access reviews.
Level 5: mission enclave, approved cloud, mission partner	Approved CAP/BCAP/ICAP path, Cisco 8000 Secure Routers or supported WAN edge, cloud firewall only where authorized, CSO-native logs.	Constrain cloud reachability to authorized services, regions, routes, and inspected connection patterns.	CSO PA scope, DISN registration, route advertisements, PPSM records, cloud audit logs, AO evidence package.

Campus And Enterprise Access Layer

The campus layer should make identity and segmentation the default. Cisco C9350 access switches are a strong fit for new high-density access where Wi-Fi 7, multigigabit access, high-power PoE, telemetry, and post-quantum readiness matter. C9550 or C9610 platforms fit campus core and aggregation roles where high-speed uplinks, hardware-rooted trust, SD-Access support, telemetry, and lifecycle runway are more important than reusing older switching designs.

• Segmentation model: create separate virtual networks or VRFs for users, privileged administration, mission workloads, OT broker access, security tools, logging, backup, guest, IoT, wireless, and cloud handoff. Use SGTs for identity and intent where ISE and TrustSec are supportable.
• Access control: use 802.1X for managed endpoints, MAB only by exception, downloadable ACLs where appropriate, posture checks where authorized, and TACACS+ for network device administration.
• Wireless: use CW917x Wi-Fi 7 for new high-density enterprise wireless and keep guest, IoT, privileged admin, mission user, and OT maintenance WLANs separate. Industrial wireless belongs to a validated OT use case, not to safety-critical control without a safety case.
• Evidence: preserve Catalyst Center inventory, software versions, device health, assurance data, path traces, configuration changes, ISE authentication records, SGT mappings, and failed authentication events.

Data Center And Mission Workload Fabric

The data center layer should be selected around the operating model. Cisco ACI is attractive when the team wants application-centric policy, tenants, VRFs, endpoint groups or endpoint security groups, contracts, and service insertion from a central policy model. Nexus 9000 VXLAN BGP EVPN is attractive when the team wants an open fabric model with explicit underlay/overlay design, NDFC lifecycle management, and direct control of routing constructs. Both can be supportable; the design should choose one fabric pattern deliberately and document why.

• ACI option: use tenants and VRFs to separate mission applications, shared services, management, logging, backup, and security tools. Use contracts for allowed application paths and service insertion for firewall inspection where required.
• VXLAN EVPN option: use VRFs, route targets, route leaking, EVPN control plane design, border leaf controls, and NDFC templates to keep route propagation deliberate and auditable.
• Firewall placement: use Secure Firewall 6100 for very high-throughput data center inspection and Secure Firewall 4200 for enterprise, campus, and IDMZ boundaries where the performance profile fits.
• Microsegmentation: use Cisco Secure Workload, ACI policy, VXLAN GPO, or Hypershield/N9300 patterns only after dependency mapping, change-control fit, and authorization scope are clear.
• Evidence: preserve APIC or NDFC changes, firewall deployments, flow logs, workload policy changes, route-leak approvals, vulnerability data, and restore evidence for mission systems.

WAN, CAP, And Cloud Connectivity

Private connectivity is not automatically trusted connectivity. For IL5-aware design, cloud and mission partner paths need explicit routing, inspection, registration, and authorization. Commercial off-prem IL4/IL5 CSOs commonly require approved CAP or BCAP patterns. DoD private or on-prem patterns may use different approved connection models. The network design should show the exact route advertisement boundaries, inspection points, encryption domains, logging points, and service scope.

• WAN edge: use Cisco 8000 Series Secure Routers, Catalyst 8300/8500, or supported SD-WAN edges according to throughput, crypto, operational, and authorization needs.
• Routing: document advertised prefixes, accepted prefixes, route filters, default route behavior, route leaking, blackhole routes, failover behavior, and who can approve a route change.
• Inspection: inspect traffic at data center, campus, cloud edge, and CAP handoff points according to the risk and required control set. Do not make cloud private links an inspection bypass.
• Management: evaluate cloud-delivered SD-WAN, security management, Secure Access, XDR, and Security Cloud Control against the mission authorization boundary before using them with IL5 data or control-plane information.

OT And Purdue Model Security

The OT side should be designed as zones and conduits, not as a set of VLANs waiting to be routed. The safest starting point is passive visibility through Cyber Vision, then segmentation based on observed normal communication, then controlled enforcement during plant-approved windows. Vendor access should move away from broad VPNs and toward time-bound, approved, logged access through jump paths, PAM, and Cisco Secure Equipment Access where it fits the environment.

• Level 0-2: keep controllers, HMIs, safety systems, engineering workstations, and cell servers segmented by production cell or safety boundary. Use IE3400, IE3500, or IE9300 where rugged switching and Cisco industrial integration are needed.
• Level 3: place site historians, MES, patch staging, backup staging, local identity relays, DNS/NTP relays, Cyber Vision Center, and OT management services in a site operations zone.
• Level 3.5: make the industrial DMZ the only brokered path for historian replication, file transfer, vendor access, SIEM forwarding, patch relay, backup relay, and carefully scoped telemetry to mission systems.
• Cyber Vision: use embedded sensors where supported, update the Knowledge DB through an approved process, feed Cyber Vision context to ISE or firewall policy where supportable, and preserve passive discovery records for evidence.
• Safety rule: do not place experimental quantum networking, QKD pilots, broad cloud management, or automated blocking in production OT without plant-owner approval and AO acceptance.

Identity, Privileged Access, And Zero Trust

Identity is a control surface, not just a login service. Cisco ISE should act as the network policy brain for endpoint identity, device profiling, TACACS+ administration, pxGrid integrations, and segmentation context. For DoD environments, CAC/PIV, DoD PKI, federation, MFA, PAM, privileged session recording, and break-glass monitoring should be designed explicitly. Duo Federal or Cisco Secure Access can be useful only where the authorization model, data handling, and mission boundary allow them.

• Define separate administrator groups for campus, data center, firewall, OT, cloud, backup, PKI, IAM, and security tooling.
• Require privileged access through hardened jump paths with MFA, PAM, command logging, and session recording.
• Use just-in-time elevation for high-risk actions such as firewall rule changes, route leaks, device reloads, OT engineering workstation access, and cloud IAM changes.
• Preserve ISE, TACACS+, PAM, IdP, and device-administration logs in the evidence plane with synchronized time.

Security Monitoring, Evidence, And Recovery

For IL5-aware design, telemetry is only useful if it can be trusted, retained, searched, and mapped to controls. Cisco Secure Firewall events, NetFlow/IPFIX, ISE sessions, Catalyst Center assurance, Nexus Dashboard events, APIC/NDFC changes, Cyber Vision OT events, DNS, NTP, PKI, cloud audit logs, endpoint logs, backup status, and restore-test results should feed an approved SIEM/SOAR and evidence store. Splunk and Cisco XDR can be valuable, but cloud-delivered analytics must be evaluated against the authorization boundary before production use.

• Network telemetry: collect flow records, firewall events, DNS events, authentication records, failed access attempts, route changes, and configuration drift.
• OT telemetry: collect Cyber Vision asset inventory, industrial protocol flows, vulnerability context, baseline deviations, and secure remote access records.
• Evidence retention: use immutable or tamper-resistant storage for control evidence, restore reports, firewall changes, IAM reviews, and incident records.
• Quantum hardware placement: use Quantum DXi, ActiveScale, or Scalar systems for backup, archive, cyber recovery, and evidence preservation where approved. Keep them in the backup/evidence plane, not in the live control path.

Quantum-Safe And Quantum-Realm Placement

The practical quantum work in this architecture is crypto agility, post-quantum readiness, and durable evidence protection. Cisco has published a post-quantum cryptography roadmap and positions current smart switching and secure routing around post-quantum readiness. Cisco 8000 Series Secure Routers and supported IOS XE capabilities can be evaluated for post-quantum-safe IPsec planning, including RFC 8784 post-quantum preshared keys and Cisco SKIP where supported. This should start in a lab or pilot before it becomes production policy.

• Create a crypto inventory for TLS, SSH, IPsec, MACsec, certificates, device identity, firmware signing, VPNs, API endpoints, wireless, controllers, firewalls, and cloud paths.
• Prefer platforms with current support, hardware-rooted trust, crypto agility, telemetry, and software lifecycle runway.
• Use MACsec on high-value campus, core, OT backhaul, and data center links where latency, key management, and platform support fit.
• Keep QKD, quantum networking research, quantum entanglement distribution, or QRNG-backed key-source experiments outside the production IL5 boundary unless the AO approves a specific pilot and the limitations are documented.

Build Order

1. Define the boundary: identify the mission system, data types, CSO scope, users, OT assets, external partners, management systems, and inherited controls.
2. Map Purdue levels: place each OT asset, historian, broker, workstation, and control path into Level 0/1, Level 2, Level 3, Level 3.5, Level 4, or Level 5.
3. Build the segmentation matrix: define VRFs, VNs, SGTs, ACI/EVPN constructs, firewall zones, route leaks, cloud routes, and policy owners.
4. Deploy visibility first: collect flow data, Cyber Vision inventory, ISE endpoint identity, firewall events, and route/config state before broad enforcement.
5. Implement the IDMZ: move historian replication, file transfer, vendor access, patch relay, backup relay, and SIEM forwarding into explicit brokered services.
6. Enforce deny-by-default: permit only documented conduits and test rollback before making enforcement changes in OT or mission zones.
7. Connect cloud only through approved paths: validate CAP/BCAP/ICAP routing, inspection, logging, PPSM, and CSO PA scope before sending mission traffic.
8. Prove recoverability: test restore paths, offline recovery, immutable retention, evidence export, and incident isolation procedures.
9. Operate continuously: monitor drift, vulnerabilities, routes, firewall changes, privileged access, backup health, OT anomalies, and control evidence.

Evidence Package Checklist

Artifact	Why It Matters	Likely Source
Authorization boundary diagram	Shows what is inside and outside the IL5 system boundary.	Architecture team, Mission Owner, AO package.
Purdue zone and conduit diagram	Shows OT separation and brokered Level 3.5 paths.	OT owner, Cyber Vision, firewall policy.
VRF/VN/SGT/EPG matrix	Shows macrosegmentation and identity-based access.	ISE, Catalyst Center, ACI/NDFC, design repository.
Firewall and PPSM matrix	Shows allowed ports, protocols, owners, and inspection points.	FMC/SCC where authorized, change system, PPSM records.
Route-control evidence	Shows CAP/cloud/partner paths are constrained.	WAN edge, BGP policy, route tables, cloud routing.
Privileged access records	Shows admin paths are controlled and attributable.	PAM, TACACS+, ISE, IdP, jump hosts.
OT visibility baseline	Shows normal industrial flows before enforcement.	Cyber Vision, OT owner review.
Backup and restore evidence	Shows recovery is tested, not assumed.	Quantum DXi/ActiveScale/Scalar, backup software, restore reports.
Continuous monitoring records	Shows drift, vulnerabilities, events, and incidents are managed.	SIEM/SOAR, XDR/Splunk, SNA, vulnerability tools.

Anti-Patterns To Avoid

• Calling a product or switch stack "IL5 compliant" without an AO-issued authorization for the specific mission system.
• Using "private connectivity" as shorthand for trust, inspection, registration, or authorization.
• Routing enterprise users or cloud workloads directly to Level 0-2 control networks.
• Building flat VLAN-only segmentation with broad route leaking and no identity context.
• Letting monitoring, SIEM, backup, or vulnerability tools become unrestricted pivot paths.
• Using cloud-delivered management for IL5-sensitive management or telemetry before the boundary and authorization model support it.
• Presenting QKD or quantum networking research as a current production IL5 control.
• Enforcing OT denies before passive discovery, owner review, maintenance windows, and rollback planning.

Cisco Reference Design Guides And Sources

• Cisco Validated: Design, Deploy, and Operate
• Cisco Design Zone - Campus and Branch
• Cisco Campus LAN and Wireless LAN Solution Design Guide
• Cisco SD-Access Design Guide
• Cisco Catalyst SD-WAN Design Guide
• Cisco Data Center Design Guides
• Cisco Nexus 9000 VXLAN BGP EVPN Design and Implementation Guide
• Cisco ACI Design Guide
• Industrial Plant Network Security with Cisco Secure Firewalls
• Cisco Industrial Security Design Guide
• Cisco Cyber Vision Architecture Guide
• Cisco C9350 Series Smart Switches
• Cisco C9550 Series Smart Switches
• Cisco N9300 Series Smart Switches
• Cisco 8000 Series Secure Routers
• Cisco ISE 3.5 Release Notes
• Cisco Catalyst Center Data Sheet
• Cisco Secure Access for Government Data Sheet
• Cisco Duo MFA
• Cisco Secure Workload Platform Data Sheet
• Cisco Secure Network Analytics Data Sheet
• Cisco XDR Data Sheet
• Cisco ThousandEyes Assurance
• Cisco Cyber Vision 5.5 Release Notes
• Cisco Post-Quantum Cryptography Roadmap
• Cisco IOS XE Postquantum Preshared Keys
• DISN Connection Process Guide
• NIST Post-Quantum Cryptography FIPS Announcement
• NSA Post-Quantum Cybersecurity Resources
• Quantum DXi Backup Appliances
• Quantum ActiveScale Object Storage
• Quantum Scalar i6 Tape Library

Acronym And Term Glossary

This glossary expands the DoD, Cisco, OT, cloud, identity, and security acronyms used in the reference architecture. Product model numbers such as C9350, C9550, C9610, IE3400, IE3500, IE9300, N9300, and Cisco 8000 refer to Cisco platform families rather than security acronyms.

Term	Meaning	How It Is Used In This Design
ACI	Application Centric Infrastructure.	Cisco data center fabric and policy model for tenants, VRFs, endpoint groups, contracts, and service insertion.
ACL	Access Control List.	Rules that permit or deny traffic at switches, routers, firewalls, or OT boundaries.
AO	Authorizing Official.	The risk owner who accepts residual risk and authorizes the system boundary to operate.
API	Application Programming Interface.	Automation or integration interface used by controllers, dashboards, cloud services, and security tools.
APIC	Application Policy Infrastructure Controller.	The controller cluster for Cisco ACI fabrics.
ATO	Authorization to Operate.	Formal authorization for a system to operate at a defined scope and risk level.
BCAP	Boundary Cloud Access Point.	A DoD/DISA cloud access boundary pattern used to connect approved cloud environments while protecting the DISN/DODIN boundary.
BGP	Border Gateway Protocol.	The routing protocol commonly used for WAN, cloud, EVPN, and route-exchange boundaries.
CAC	Common Access Card.	DoD smart-card credential used with PKI and MFA patterns.
CAP	Cloud Access Point.	An approved cloud connection and security boundary for DoD cloud traffic; the specific CAP/BCAP/ICAP pattern depends on the mission and connection approval path.
CAO	Connection Approval Office.	The DISN authority involved in connection registration and approval workflows.
CNAP	Cloud Native Access Point.	A DoD cloud access reference pattern for secure cloud ingress and egress when that model is approved for the mission.
CNFW	Cloud Native Firewall.	Cloud-native firewall capability used only where the CSO, region, logging, and authorization scope permit it.
CPTC	Cloud Permission to Connect.	A cloud connection approval artifact referenced in DISN cloud connection workflows.
CSP	Cloud Service Provider.	The cloud provider hosting an authorized cloud service offering.
CSO	Cloud Service Offering.	The specific cloud service, region, and feature scope authorized for use.
CSSP	Cybersecurity Service Provider.	The organization providing monitoring, detection, incident response, or security operations support.
CVD	Cisco Validated Design.	Cisco design guidance used to keep the architecture inside supportable campus, WAN, data center, and industrial patterns.
DC	Data Center.	The mission application, shared services, management, security, and backup hosting environment.
DISA	Defense Information Systems Agency.	The DoD agency associated with DISN services, connection guidance, and several cloud access processes.
DISN	Defense Information Systems Network.	The DoD network service environment that cloud and mission connections may traverse or connect to.
DMZ	Demilitarized Zone.	A controlled network segment between trust zones. In OT, the industrial DMZ brokers Level 3 and enterprise/mission paths.
DNS	Domain Name System.	Name-resolution service that should be segmented, logged, and protected inside each boundary.
DoD	Department of Defense.	The mission and compliance environment for IL5-aware architecture.
DODIN	Department of Defense Information Network.	The broader DoD information network boundary that cloud and enterprise security controls help protect.
EPG	Endpoint Group.	An ACI policy grouping used to apply contracts and segmentation policy.
EVPN	Ethernet VPN.	The BGP-based control plane often paired with VXLAN for scalable data center overlays.
FIPS	Federal Information Processing Standards.	Federal standards relevant to cryptography and security validation.
FMC	Firewall Management Center.	Cisco Secure Firewall management platform for policy, events, and change evidence.
GPO	Group Policy Option.	VXLAN policy metadata used in some Cisco segmentation designs.
HMI	Human-Machine Interface.	Operator workstation or panel used to monitor and control industrial processes.
HSM	Hardware Security Module.	Hardware used to protect cryptographic keys and sensitive crypto operations.
IAM	Identity and Access Management.	Identity, roles, permissions, federation, and cloud access controls.
IAP	Internet Access Point.	A protected boundary between DoD networks and the public internet; related to cloud access discussions but not a shortcut around authorization.
ICAP	Internal Cloud Access Point.	A DoD cloud access pattern for certain internal or on-premises cloud connection scenarios, as applicable to the approved environment.
ICS	Industrial Control System.	The industrial automation and control environment, including controllers, HMIs, historians, and engineering workstations.
IDMZ	Industrial Demilitarized Zone.	The brokered Purdue Level 3.5 boundary between OT networks and enterprise or mission networks.
IED	Intelligent Electronic Device.	An industrial or utility field device used for protection, control, automation, or monitoring.
IdP	Identity Provider.	The authentication authority used for federation, SSO, MFA, and privileged-access workflows.
IL4	Impact Level 4.	A DoD cloud impact level below IL5; included because many cloud authorization paths discuss IL4 and IL5 together.
IL5	Impact Level 5.	A DoD cloud impact level for higher-sensitivity controlled unclassified information and mission data requiring stronger isolation and controls.
IP	Internet Protocol.	The packet-networking protocol family used for addressing and routing.
IPFIX	IP Flow Information Export.	A flow telemetry standard used to send network-flow records to monitoring tools.
IPsec	Internet Protocol Security.	An encrypted IP tunnel and transport security suite used for site, WAN, and cloud paths.
ISE	Identity Services Engine.	Cisco policy platform for 802.1X, profiling, TACACS+, pxGrid, SGTs, and segmentation context.
IT	Information Technology.	Enterprise computing, identity, applications, networking, and user services outside direct process control.
KMS	Key Management Service or Key Management System.	Service used to create, store, rotate, and control cryptographic keys.
LAN	Local Area Network.	Local campus, building, or site network.
MAB	MAC Authentication Bypass.	Endpoint authentication fallback based on MAC address, used sparingly for devices that cannot support 802.1X.
MACsec	Media Access Control Security.	Layer 2 link encryption for high-value wired links where platform and key management support it.
MES	Manufacturing Execution System.	Plant operations software that often sits around Purdue Level 3.
MFA	Multi-Factor Authentication.	Authentication using more than one factor, such as certificate, token, push approval, biometric, or password.
NDFC	Nexus Dashboard Fabric Controller.	Cisco data center fabric management and automation for Nexus fabrics.
NIPRNet	Non-classified Internet Protocol Router Network.	DoD network environment commonly referenced in CAP, BCAP, ICAP, and DISN connection guidance.
NIST	National Institute of Standards and Technology.	U.S. standards body referenced for security controls, RMF, and post-quantum cryptography standards.
NSA	National Security Agency.	U.S. agency that publishes cybersecurity and post-quantum guidance for national security systems.
NTP	Network Time Protocol.	Time synchronization service needed for trustworthy logs, certificates, Kerberos, and event correlation.
OT	Operational Technology.	Industrial technology used to monitor or control physical processes.
PA	Provisional Authorization.	Authorization status or scope commonly associated with a cloud service offering.
PAM	Privileged Access Management.	Controls for administrator elevation, session brokering, recording, approval, and break-glass access.
PIV	Personal Identity Verification.	Federal smart-card credential standard used with certificates and MFA.
PKI	Public Key Infrastructure.	Certificate authorities, certificates, trust chains, and revocation services.
PLC	Programmable Logic Controller.	Industrial controller used to automate physical processes.
PoE	Power over Ethernet.	Power delivery over Ethernet cabling for access points, cameras, phones, and similar devices.
PPK	Post-quantum Preshared Key.	An IPsec enhancement used as part of post-quantum-safe planning and testing.
PPSM	Ports, Protocols, and Services Management.	DoD process and documentation for approved network services, ports, protocols, and owners.
PQC	Post-Quantum Cryptography.	Cryptography intended to resist attacks from future cryptographically relevant quantum computers.
QKD	Quantum Key Distribution.	Quantum key-distribution technology; treated here as pilot or research, not a default production IL5 control.
QRNG	Quantum Random Number Generator.	Hardware entropy source that may support key generation or crypto services where approved.
RFC	Request for Comments.	Standards-track or informational internet engineering publication, such as RFC 8784 for PPK.
RMF	Risk Management Framework.	NIST/DoD process for categorizing, selecting controls, implementing, assessing, authorizing, and monitoring systems.
RTU	Remote Terminal Unit.	Industrial remote monitoring and control device often used in utilities and distributed control environments.
SCC	Security Cloud Control.	Cisco cloud-delivered security and firewall management option, used only where authorized for the boundary.
SCCA	Secure Cloud Computing Architecture.	DoD/DISA cloud security architecture context for approved cloud access patterns.
SD-Access	Software-Defined Access.	Cisco campus fabric architecture using identity and policy-based segmentation.
SD-WAN	Software-Defined Wide Area Network.	Policy-managed WAN architecture for branch, campus, data center, and cloud connectivity.
SEA	Secure Equipment Access.	Cisco secure remote access pattern for industrial equipment where it fits the environment and authorization scope.
SGT	Security Group Tag.	Cisco TrustSec tag used to apply identity or group-based segmentation policy.
SIEM	Security Information and Event Management.	Security logging, correlation, alerting, and investigation platform.
SKIP	Session Key Import Protocol.	Cisco post-quantum-safe keying capability referenced for controlled testing where supported.
SNA	Secure Network Analytics.	Cisco network-flow analytics platform, formerly known as Stealthwatch.
SOAR	Security Orchestration, Automation, and Response.	Security workflow and response automation used with SIEM or detection tools.
SOC	Security Operations Center.	Team or function that monitors, investigates, and responds to security events.
SSH	Secure Shell.	Encrypted remote administration protocol for network and server management.
SSO	Single Sign-On.	Federated authentication experience where users authenticate once to access multiple systems.
TACACS+	Terminal Access Controller Access-Control System Plus.	AAA protocol commonly used for network device administrator authentication, authorization, and accounting.
TLS	Transport Layer Security.	Encrypted session protocol used for web, API, controller, and service communications.
UCS	Unified Computing System.	Cisco compute platform family for server and data center workloads.
VDMS	Virtual Datacenter Management Services.	Cloud management-service component referenced in DISA SCCA onboarding contexts.
VDSS	Virtual Datacenter Security Stack.	Cloud security stack component referenced in DISA SCCA and BCAP/ICAP onboarding contexts.
VLAN	Virtual LAN.	Layer 2 segmentation construct; useful, but not sufficient by itself for IL5-aware segmentation.
VN	Virtual Network.	Logical network or segment, commonly used in SD-Access or overlay designs.
VPN	Virtual Private Network.	Encrypted tunnel or private overlay path for remote, site, partner, or cloud connectivity.
VRF	Virtual Routing and Forwarding.	Separate routing table used for macrosegmentation and tenant separation.
VXLAN	Virtual Extensible LAN.	Overlay encapsulation used with EVPN or other control planes to scale Layer 2 and Layer 3 segmentation.
WLAN	Wireless LAN.	Wireless local network used for enterprise, guest, IoT, and approved maintenance access patterns.
XDR	Extended Detection and Response.	Detection, correlation, investigation, and response capability spanning multiple security tools and telemetry sources.