CCIE Security: The Complete Study Hub

CCIE Security study hub: blueprint domains mapped to hands-on PingLabz labs

The CCIE Security lab is not a written test with a keyboard attached. It is an eight-hour, hands-on practical exam where you plan, deploy, operate, and optimize the end-to-end security of a dual-stack (IPv4 and IPv6) enterprise network, then troubleshoot it when the graders break it under you. You do not get credit for knowing what a crypto map is. You get credit for building one that passes traffic, surviving a failover with zero packet loss, and explaining why the tunnel that should be up is stuck in MM_WAIT_MSG2.

This hub maps every domain of the current CCIE Security v6.1 blueprint to the PingLabz articles that cover it, all grounded in real captures from a Cisco Modeling Labs (CML) rack: cat8000v and IOL-XE routers, asav firewalls, and a real Debian host bridged into the topology. Where a feature genuinely does not exist on virtual hardware, we say so and show the parser rejecting it, because knowing the platform boundary is itself an exam skill. Use this page as your table of contents: work a domain top to bottom, follow the links, and lab everything you read.

The Two Exams: Qualifying, Then the Lab

CCIE Security is a two-stage certification, and the stages test very different muscles.

Stage 1, the qualifying exam (350-701 SCOR). A 120-minute written exam on core security technologies: network security, cloud security, content security, endpoint protection, secure network access, visibility, and enforcement. It is the same exam that anchors CCNP Security, so passing it also moves your professional-level track forward. You must pass SCOR before you are allowed to book the lab. (Cisco is refreshing SCOR from v1.1 to v2.0 in late 2026, so check the current blueprint before you schedule.)

Stage 2, the practical exam (v6.1). Eight hours, hands-on, on real Cisco security gear. Cisco describes it as designing, deploying, operating, and optimizing end-to-end security for a dual-stack enterprise network, and you are expected to program and automate the network inside the exam as well. The lab is weighted across five domains: Perimeter Security and Intrusion Prevention (20%), Secure Connectivity and Segmentation (20%), Security Infrastructure (15%), Identity Management, Information Exchange and Access Control (25%), and Advanced Threat Protection and Content Security (20%).

What the lab actually asks of you is muscle memory under time pressure: bring up a FlexVPN hub with IKEv2 and a AAA authorization policy from a blank config, get OSPF adjacencies through an ASA in transparent mode, tune CoPP so the control plane survives a flood, then find the one NAT rule in the wrong section that is silently black-holing an inbound service. Reading about these does almost nothing. Building them, breaking them, and reading the counters is the whole game. That is why every article below is built on captured output you can reproduce.

Domain 1: Perimeter Security and Intrusion Prevention (20%)

This domain is firewalls: Cisco ASA and Firepower Threat Defense (FTD) deployment modes, NAT, application inspection, high availability, and the IOS/IOS XE Zone-Based Firewall. PingLabz has deep, lab-proven coverage of the ASA and IOS ZBF halves. The FTD and FMC half is on the backlog (see the honest note at the end of this section), so it is listed there rather than linked to pages that do not exist yet.

ASA Deployment Modes, Contexts, and Transparent Firewalling (1.1)

1.1
Routed mode vs transparent mode on the ASA
When the firewall is a router hop versus an invisible bump-in-the-wire, and what changes for your ACLs and NAT.
1.1
Configuring a transparent (Layer 2) firewall
Bridge groups, BVI addressing, and getting routing protocols to adjacency across a stealth firewall.
1.1
Transparent-mode EtherType ACLs
Filtering non-IP traffic (BPDUs, ARP, MPLS) that a routed firewall never even sees.
1.1
Multiple context mode on the ASA
Carving one firewall into virtual firewalls, and the classification rules that decide which context a packet lands in.
1.1
Security contexts with shared interfaces
MAC-based and NAT-based classification when contexts share a physical link.
1.1
Resource classes for security contexts
Stopping one noisy context from consuming the whole firewall's connection and xlate budget.

Firewall Features: NAT and Application Inspection (1.2, 1.3)

NAT on the modern ASA is a table with sections and an order of operations, not a pile of commands. Get the order wrong and the right rule never fires. The Modular Policy Framework (MPF) is how the ASA does everything from protocol inspection to TCP normalization, and it is the single most reusable pattern on the box.

1.2
The ASA NAT table: sections, order, and which rule wins
Manual NAT (before auto), auto NAT, then manual NAT (after auto), and how to read the numbered table.
1.2
NAT and ACLs together on ASA 8.3+
Why your interface ACL references real IPs, not mapped IPs, and how that trips people up post-8.3.
1.2
Destination NAT (policy NAT) for inbound services
Publishing an internal server with twice-NAT and conditioning it on the source.
1.2
Static identity NAT: translating nothing, on purpose
The NAT-exempt pattern that keeps VPN-bound traffic from being PATed.
1.2
The Modular Policy Framework: class-map, policy-map, service-policy
The one framework behind inspection, QoS, and connection limits on the ASA.
1.2
Application inspection engines in practice
Why FTP, SIP, and DNS need inspection to build the return pinhole, with real conn-table proof.
1.2
Custom Layer 7 inspection: regex and match conditions
Blocking specific application behavior with a custom inspection policy-map.
1.2
TCP normalization: the silent connection killer
The default TCP state checks that quietly drop asymmetric or out-of-spec flows.
1.3
Zone-Based Firewall on IOS XE: zones, zone-pairs, policy
The IOS/IOS XE firewall model (1.3.b) built and verified on cat8000v.
1.3
ZBF port-maps: inspecting apps on non-standard ports
Teaching the zone firewall about a service running off its well-known port.
1.3
Nested class-maps in ZBF: layered policy
Composing match-any and match-all class-maps for real-world traffic policy.
1.3
VRF-aware NAT on IOS XE
IOS XE NAT (1.3.c) when the inside and outside live in different VRFs.

High Availability and Clustering (1.8), Routing-Protocol Security (1.10)

This is where a virtual lab teaches you as much by what it refuses as by what it builds. Active/Standby stateful failover works perfectly on asav and is worth building until it is reflex. The hardware-oriented HA features (redundant interfaces, EtherChannel, Active/Active, clustering) are concept-plus-config on virtual gear, so those articles pair the design with the real platform boundary.

1.8
Active/Standby failover configuration
LAN-based failover, the failover link, and config replication between the pair.
1.8
Stateful failover and interface tracking
Replicating the conn and xlate tables so an active-unit failure is seamless (proven zero-loss in the lab).
1.8
Active/Active failover: failover groups and asymmetry
Multi-context Active/Active design and the asymmetric-routing reality it creates.
1.8
ASA clustering: spanned vs individual interface mode
How a cluster presents one logical firewall, and where the two interface modes diverge.
1.8
Redundant interfaces: the simplest link HA
Active/backup physical links under one logical interface, and how it interacts with failover.
1.8
EtherChannel on the ASA: port-channels and LACP
Bundling links for bandwidth and link HA, plus its interaction with failover.
1.8
Choosing ASA HA: failover vs clustering vs contexts
A decision framework for which availability model fits which requirement.
1.10
Dynamic routing on the ASA: what it will and won't do
The firewall as a routing peer, and the design limits that separate it from a router.
1.10
OSPF on the ASA: areas, redistribution, quirks
Getting adjacencies up through the firewall and the ASA-specific gotchas.
1.10
EIGRP on the ASA: neighbor gotchas
AS matching, the silent empty neighbor table, and how to prove the adjacency.
1.10
RIPv2 on the ASA (and why you'd still see it)
v2 auth, and why the RIP route loses on administrative distance anyway.

Policies, Connectivity, and Management (1.9, 1.11)

1.9
Security levels: inside, outside, DMZ
The trust model that governs traffic flow before a single ACL is written.
1.9
ASA ACLs and object groups
Interface access rules, object-group scaling, and the implicit permit high-to-low.
1.11
ASA packet flow: interface ACL to NAT to route lookup
The exact order the ASA processes a packet, which is how you troubleshoot it.
1.11
The packet-tracer command
Simulating a flow through every phase to find the rule that drops it.
1.9
ASDM access: setup, TLS, and whether to use it
Getting the GUI up, and when the CLI is still the faster tool.

Domain 2: Secure Connectivity and Segmentation (20%)

This is the heart of PingLabz's security coverage: IPsec, IKEv2, FlexVPN, GETVPN, DMVPN, the ASA VPN suite, an IOS CA you can actually run, and the segmentation building blocks (VLAN, PVLAN, GRE, VRF-Lite). Start with the IPsec VPN pillar and the DMVPN pillar, then work the clusters below.

IPsec and IKEv2 Site-to-Site (2.3)

2.3
IPsec explained: IKE Phase 1, Phase 2, and what gets encrypted
The mental model for every tunnel: SAs, the two phases, and where ESP fits.
2.3
Site-to-site VPN with crypto maps on IOS XE
The classic ACL-plus-crypto-map design, still all over production networks.
2.3
Static VTI (SVTI): the modern site-to-site design
Routable tunnel interfaces that replace crypto ACLs with a routing decision.
2.3
Crypto maps vs VTI: which design to pick
The tradeoffs that decide which of the two site-to-site models you deploy.
2.3
IKEv2 explained: why it replaced IKEv1
The smarter exchange, the built-in defaults, and the SA model that changed.
2.3
IKEv2 site-to-site with SVTI
The config you should actually deploy: IKEv2 profiles bound to a tunnel interface.
2.3
IKEv2 site-to-site with crypto maps
Running IKEv2 under the legacy crypto-map model when a peer requires it.
2.3
GRE over IPsec: why tunnels and encryption belong together
A real before/after capture showing GRE leaking inner IPs, then ESP-only after protection.
2.3
NAT traversal (NAT-T): surviving a NAT device
UDP 4500 encapsulation and how IPsec detects a NAT in the path.
2.3
VRF-aware IPsec: keeping VPNs in their lane
Front-door and inside VRFs so overlapping customer tunnels stay isolated.
2.3
Troubleshooting IPsec: Phase 1 up, Phase 2 down
The classic failure signatures and the debugs that actually localize them.

FlexVPN and GETVPN (2.3, 2.4)

2.3
FlexVPN explained: one framework for every VPN shape
The IKEv2-based framework unifying site-to-site, hub-spoke, and remote access.
2.3
FlexVPN site-to-site on IOS XE
IKEv2 profiles, the AAA authorization policy, and route injection with no IGP.
2.3
FlexVPN spoke-to-spoke: dynamic tunnels without DMVPN
An honest field report: working hub-spoke, plus a real NHRP-shortcut boundary on virtual gear.
2.3
GETVPN explained: group encryption without tunnels
Tunnel-less encryption over a private WAN, and the key-server / group-member model.
2.3
GETVPN configuration: key server, group members, GDOI
Building the GDOI group and proving the shared SA across members.
2.4
GETVPN redundancy: COOP key servers and rekey survival
Cooperative key servers so a KS failure does not stop the rekey (a VPN-HA topic, 2.4).
2.4
Dual-hub DMVPN: redundancy that actually fails over
The dual-hub deployment called out directly in blueprint 2.4.b.
2.3
DMVPN with IKEv1 vs IKEv2: config and migration
Moving a DMVPN cloud from IKEv1 to IKEv2 protection without an outage.

IOS CA and Certificate Authentication (2.2)

2.2
Running a Cisco router as a CA server
A real PKI you can lab: the IOS CA that issues certs for VPN authentication (2.2).
2.2
Certificate authentication for IPsec
Trustpoints, SCEP enrollment, and revocation so tunnels auth by cert, not PSK.

ASA Remote-Access and LAN-to-LAN VPNs (2.1, 2.3)

2.1
AnyConnect SSL VPN on the ASA
The client-based remote-access VPN (2.1) from address pools to group-policy.
2.1
AnyConnect IKEv2 VPN on the ASA
The IPsec/IKEv2 flavor of AnyConnect and when to prefer it over SSL.
2.1
Split tunneling on the ASA
Deciding which traffic rides the tunnel and which goes direct.
2.1
VPN group policies and tunnel groups
Mapping users to policy: the connection-profile to group-policy chain.
2.1
AAA for VPN: LDAP, RADIUS, TACACS+
Authenticating remote-access users against an external identity store.
2.1
Dynamic Access Policies (DAP)
Posture-driven access decisions at connection time.
2.1
Clientless SSL VPN is gone: what replaced WebVPN
The real 9.17+ change: clientless WebVPN removed, and the modern alternative.
2.3
LAN-to-LAN IPsec VPN on the ASA with IKEv2
The ASA side of an IKEv2 site-to-site tunnel (blueprint 2.3, L2L).
2.3
Migrating an ASA site-to-site tunnel to IKEv2
Cutting a live L2L tunnel from IKEv1 to IKEv2 with minimal disruption.
2.3
IPsec through an ASA: NAT-T and ESP pass-through
Why a tunnel transiting a firewall stalls, and how to let ESP or NAT-T through.

Segmentation: VLAN, PVLAN, GRE, VRF-Lite, SGT (2.5, 2.6)

2.5
Private VLANs: isolating hosts that share a subnet
Primary, isolated, and community VLANs (2.5.b) for intra-subnet segmentation.
2.5
VLAN ACLs (VACLs): filtering inside a VLAN
Enforcing policy on traffic that never leaves its own VLAN.
2.5
GRE tunnels: the multiprotocol overlay
The GRE building block (2.5.c) that carries routing and multicast over IP.
2.5
VRF-Lite in practice: VRF-aware NAT
Keeping routing tables separated per VRF, then translating between them.
2.6
Macro (VN) vs micro (SGT) segmentation
The TrustSec SGT model (2.6) as applied in an SD-Access fabric.

Domain 3: Security Infrastructure (15%)

Domain 3 is hardening the network devices themselves: control-plane protection, management- and data-plane defense, Layer 2 security, and the monitoring and automation plumbing. The infrastructure security pillar ties the router-hardening pieces together; the VLANs and Layer 2 switching pillar anchors the switch-side controls.

Control-Plane and Device Hardening (3.1, 3.2)

3.1
CoPP vs CPPr: which control-plane defense to deploy
Control Plane Policing versus Protection, and where each one fits (3.1.a).
3.1
Control Plane Protection (CPPr) with port-filtering
Sub-interface policing and port-filtering beyond a flat CoPP policy.
3.2
Router service hardening: turning off what you never needed
Disabling source routing, small servers, and the legacy services (3.1.b, 3.2).
3.2
ASA management access done right
SSH, HTTPS, SNMPv3, NTP, and logging locked down (3.2.c) on the firewall.

Data-Plane and Anti-Spoofing (3.3, 3.7)

3.3
Anti-spoofing on the edge: ACLs, uRPF, and RFC 2827
Unicast RPF and ingress filtering (3.3.a, 3.7.b / BCP 38) to drop spoofed sources.
3.3
QoS as a data-plane protection tool
Rate-limiting and prioritization (3.3.b) that also blunts a resource-exhaustion attack.

Layer 2 Security (3.4)

3.4
Dynamic ARP Inspection and IP Source Guard
DAI (3.4.a) and IPSG stopping ARP poisoning and IP spoofing at the port.
3.4
DHCP snooping: bindings, Option 82, trusted ports
The binding table (3.4.e) that DAI and IPSG both depend on.
3.4
Static ARP ACLs: inspecting ARP without DHCP snooping
Locking ARP on static-IP segments where there is no snooping binding to trust.
3.4
Storm control: stopping broadcast floods at the port
Threshold-based suppression of broadcast, multicast, and unknown-unicast storms.
3.4
IPv6 RA Guard and DHCPv6 Guard
First-hop security (3.4.f) blocking rogue router advertisements and DHCPv6 servers.
3.4
The Layer 2 attack surface: a hardening checklist
Port security, STP guards, VACLs, and PVLANs assembled into one defensible baseline.
3.4
STP security: root guard, BPDU guard, loop guard
The spanning-tree hardening (3.4.c) that keeps a rogue switch off the root.

Monitoring, NTP, and Automation (3.6, 3.9)

3.6
SNMPv3 in production: users, groups, views, traps
Authenticated, encrypted SNMP (3.6.b) instead of a community string in the clear.
3.6
ASA syslog and logging levels
Structuring firewall logs (3.6.c) so the message you need is not buried.
3.6
Embedded Packet Capture: Wireshark inside the router
On-box capture (part of 5.3 too) when you cannot get a SPAN in place.
3.6
Model-driven telemetry: gRPC dial-out
Streaming telemetry as the modern replacement for SNMP polling.
3.2
NTP authentication: trusting the clock your logs depend on
Keyed NTP so an attacker cannot skew the timestamps your forensics rely on.
3.9
On-box Python: scripting IOS XE from the inside
The Python interpreter (3.9) that automates config and verification on the device.
3.9
JSON vs XML vs YAML for network engineers
The three encoding formats (3.9.b) behind every REST and NETCONF payload.
3.9
Jinja2 templates for network configs
Rendering consistent device configs from variables, the automation half of the lab.

Wireless security (3.5) and the broader monitoring stack are covered in the Cisco wireless guide and the network automation pillar.

Domain 4: Identity Management, Information Exchange, and Access Control (25%)

This is the single largest domain on the lab at 25 percent, and it is built around Cisco ISE: 802.1X and MAB, guest and BYOD onboarding, posture, profiling, external identity sources, DUO MFA, and IBNS 2.0. PingLabz has the network-access foundation live in the 802.1X pillar, and the ISE control layer is the next cluster on the build list.

4.4
802.1X and MAB: port-based access control
The switch-side of network-access AAA (4.4): the supplicant, authenticator, and RADIUS server roles, EAP, and MAC Authentication Bypass.

The identity control plane itself (ISE personas and scaling, guest lifecycle, BYOD onboarding, posture assessment, endpoint profiling, external identity sources, DUO, and IBNS 2.0 / C3PL) is on the backlog. A dedicated ISE image (ISE 3.5) is now staged on the CML server, so this cluster is next up rather than hypothetical. Until it publishes, this hub will not link ISE articles that do not exist. See the backlog section below.

Domain 5: Advanced Threat Protection and Content Security (20%)

Domain 5 is the Cisco content-security and threat portfolio: AMP (now Secure Endpoint), Umbrella DNS-layer security, WSA and ESA, SMA, Stealthwatch, and packet capture and analysis. The packet-capture skill (5.3) is live today; the appliance-based content-security products are on the backlog.

5.3
Packet capture and analysis on IOS XE
Embedded Packet Capture and the capture-then-Wireshark workflow (5.3).
5.3
Packet capture from the ASA CLI
Capturing on the firewall data path, including the asp-drop capture for silent drops.

AMP/Secure Endpoint, Umbrella (DNS, RBI, CASB, DLP), WSA and ESA content security, WCCP redirection, and the SMA/Stealthwatch integration story are not yet covered. They are listed honestly in the backlog rather than linked.

If you are working the domains in study order rather than exam-weight order, this sequence builds each layer on the one below it:

  1. Firewall fundamentals first. ASA security levels, packet flow, and NAT order of operations, then the MPF and inspection engines. You cannot troubleshoot a VPN through a firewall you do not understand.
  2. Then VPNs, in this order: IPsec IKE phases, crypto maps, SVTI, IKEv2, then FlexVPN, then GETVPN, then DMVPN redundancy. Add the IOS CA and certificate auth once the tunnels work with pre-shared keys.
  3. Then infrastructure hardening. CoPP/CPPr, anti-spoofing and uRPF, router service hardening, then the full Layer 2 stack (DHCP snooping first, because DAI and IPSG depend on it).
  4. Then identity. 802.1X and MAB now; ISE, posture, and BYOD when that cluster publishes.
  5. Automation and capture throughout. On-box Python, telemetry, and packet capture are not a separate study block; fold them into every domain as verification tools.

The Pillar Guides

Each pillar below is a full cluster hub with its own article index. These seven carry the bulk of the CCIE Security-relevant material on PingLabz:

IPsec VPN
IKE phases, crypto maps, SVTI, IKEv2, FlexVPN, GETVPN, PKI, and VRF-aware IPsec.
Cisco ASA Firewall
NAT, MPF and inspection, HA and failover, contexts, transparent mode, and ASA VPNs.
DMVPN
Phase 1/2/3 designs, NHRP, dual-hub redundancy, and IKEv2-protected clouds.
Infrastructure Security
CoPP/CPPr, uRPF and anti-spoofing, NTP auth, and router service hardening.
VLANs and Layer 2 Switching
VLANs, trunking, PVLANs, VACLs, and the Layer 2 attack-surface controls.
IPv6
Addressing, routing for IPv6, first-hop security, tunnels, NAT64, and transition.
802.1X
Port-based access control, EAP, MAB, and the network-access AAA foundation.

Dual-Stack Is Not Optional: IPv6 Security and Services

The CCIE Security lab is explicitly dual-stack, which means every control you build has an IPv6 counterpart the graders can test. The IPv6 pillar covers the routing and transition mechanisms; the first-hop security articles map directly to blueprint 3.4.f.

v6
EIGRP for IPv6: classic and named mode
Running EIGRP over IPv6 so the overlay is dual-stack end to end.
v6
IS-IS for IPv6: multi-topology and the single-topology trap
The IGP that many SP-adjacent security designs still run for v6.
v6
IPv6 over IPv4 tunnels: manual, GRE, and 6to4
Carrying v6 across a v4-only core, a segmentation and transition building block.
v6
NAT64: stateful, stateless, and the DNS64 half
Translating between v6-only clients and v4-only servers during transition.
v6
IPv6 transition mechanisms: which one, and when
A decision map across dual-stack, tunneling, and translation.
v6
IPv6 ND inspection, snooping, and source guard
First-hop security part 2: the v6 equivalents of DHCP snooping and IPSG.

What a Home Lab Can and Cannot Prove

A good study lab is honest about its own boundaries, because on the real exam you are expected to know which features live on which platform. Everything below was hit during the build of this material on CML, and each limit is a thing worth being able to reason about out loud.

What the virtual lab proves cleanly

  • ASA Active/Standby stateful failover, with real zero packet loss. A 45-packet stream through the firewall survived a forced active-unit failover with 45 of 45 received, 0% loss, and the full Standby-Ready to Active state machine in the failover history. This is the anchor HA demo, and it is completely real on asav.
  • The entire IOS/IOS XE VPN suite. Crypto maps, SVTI, IKEv2, FlexVPN hub-and-spoke, GETVPN with COOP key servers, VRF-aware IPsec, and a router-based CA all come up and pass traffic on cat8000v and IOL-XE.
  • The control-plane and Layer 2 hardening stack. CoPP/CPPr, DHCP snooping, DAI, IP Source Guard, VACLs, and private VLANs all enforce and can be verified with real counters.
  • Good news on licensing: cat8000v 17.18.02 came up at License Level network-advantage straight from the day0 config on first boot, with no reload, so every crypto command was accepted immediately.

Where the virtual platform draws a hard line (and that is the lesson)

  • asav supports only Active/Standby. The parser flatly rejects the hardware-oriented HA and scale features: interface Redundant1, interface Port-channel1 / channel-group, mode multiple (multiple-context mode, and therefore Active/Active and resource classes), and cluster interface-mode spanned all return % Invalid input. This matches Cisco's own docs (the ASAv does not support multiple contexts or clustering), so those articles teach the concept, show the hardware config, and show the real refusal. Knowing the boundary is the exam-relevant skill.
  • Clientless SSL VPN (WebVPN) is removed on ASA 9.17 and later. If your study notes still show a clientless portal, they predate the removal. The modern answer is the AnyConnect / Secure Client model.
  • The Zone-Based Firewall needs a licensed cat8000v. ZBF is not available on IOL-XE, so the ZBF articles were built on cat8000v with network-advantage. Picking the right node for the feature is part of building a lab that can actually prove the thing you are studying.
  • Virtual IOL does not fully forward every data-plane feature. Some counters that would move on real silicon (uRPF drop counters, NAT64 translation entries) stay flat on the virtual data path. The configuration and control-plane logic are correct and testable; the packet-forwarding proof needs different gear. Recognizing that a clean config with a zero counter can be a platform artifact, not a mistake, is a genuine troubleshooting skill.
  • FMCv is a 30-to-45-minute boot, and ftdv takes another 15-to-25 minutes to initialize before registration. That boot budget is exactly why the FTD/FMC cluster is on the backlog rather than rushed, and it is a real planning lesson for anyone building an FTD lab at home: start the appliances first and do other work while they come up.
  • Honest VPN edge case: on cat8000v 17.18.02, FlexVPN hub-and-spoke worked fully (both spokes authenticated, routes injected, spoke-to-spoke traffic passed), but the NHRP shortcut never fired, so spoke-to-spoke traffic hairpinned through the hub with every NHRP counter at zero. The article is written as a field report with the real 2-hop traceroute, not a faked 1-hop result, and points to the DMVPN cluster where NHRP shortcut is proven working on IOL-XE. Being able to tell a control-plane bug from a platform behavior is the point.

Topical authority is built by not faking coverage. The following blueprint areas are genuinely in progress and are listed here rather than linked to pages that do not exist:

NGFW: Firepower Threat Defense and FMC
Blueprint 1.4, 1.5, 1.6 and the FTD half of Domain 1. The FTD lab (FMCv plus ftdv) is fully built and boots; the articles are pending real captures because of the long appliance boot times. No FTD or FMC articles are linked from this hub until they publish.
Identity: Cisco ISE
Most of Domain 4: ISE personas and scaling, guest lifecycle, BYOD onboarding, posture assessment, endpoint profiling, external identity sources, DUO MFA, pxGrid, and IBNS 2.0 / C3PL. An ISE 3.5 image is staged on the CML server, so this identity and posture cluster is next up.
Content Security and Advanced Threat
Most of Domain 5: AMP / Secure Endpoint, Umbrella (DNS security, RBI, CASB, DLP), WSA and ESA content security, WCCP redirection, and the SMA / Stealthwatch integration story.
TrustSec and MACsec
Deeper SGT/SXP propagation (2.6) and MACsec (802.1AE) link encryption beyond the SD-Access micro-segmentation article already linked above.

Frequently Asked Questions

Is CCIE Security worth it in 2026?

For the right person, yes. The certification signals that you can design and operate end-to-end security on Cisco gear under pressure, and it remains one of the few credentials that is validated by an eight-hour hands-on lab rather than a multiple-choice test. The honest caveats: it is a large time investment (typically a year or more of lab hours), the technology set is broad and shifts with each blueprint (FTD, ISE, and cloud security keep growing), and it is most valuable if your role or target role is genuinely security-focused. If you want the depth but not the exam, the same lab practice makes you materially better at the day job either way.

How do I build a CCIE Security home lab?

Cisco Modeling Labs (CML) is the practical foundation. It runs cat8000v and IOL-XE routers, IOL-L2 switches, and asav firewalls, which covers Domains 2 and 3 and most of Domain 1 outright. Add ftdv and FMCv for the NGFW domain (budget the RAM: FMCv wants 32 GB and a 30-to-45-minute boot), and an ISE VM for Domain 4. Bridge a real Linux host into the topology so you have a genuine client for testing VPNs, captures, and posture. The recurring lesson from building this material: match the node to the feature (ZBF needs a licensed cat8000v, not IOL-XE) and start the heavyweight appliances first so they are ready when you are.

ASA or FTD for the lab?

Both, because the blueprint tests both. The ASA is where you build the muscle memory for NAT order of operations, the Modular Policy Framework, failover, and contexts; it boots fast and is forgiving to lab. FTD (managed by FMC or FDM) is where the NGFW features live: SSL inspection, user identity, geolocation, AVC, and intrusion policy. The practical approach is to master the ASA first because its concepts underpin FTD, then layer FTD on top. Note that on virtual asav the hardware HA and scale features (Active/Active, clustering, contexts) are concept-only, so you will lab those designs on paper and prove Active/Standby stateful failover live.

What is the difference between the CCIE Security written and lab exams?

The written qualifying exam (350-701 SCOR) is a 120-minute test of core security knowledge that you must pass first, and it doubles as the CCNP Security core exam. The practical exam (v6.1) is a separate eight-hour hands-on lab where you design, deploy, operate, optimize, and troubleshoot a real dual-stack network. Passing the written does not get you the CCIE; it gets you the right to book the lab. The two test different things: recall versus execution under time pressure.

Does the CCIE Security lab really test IPv6?

Yes, explicitly. Cisco describes the exam as end-to-end security of a dual-stack (IPv4 and IPv6) enterprise network, so IPv6 is not a separate section you can skip; it runs through every domain. Expect to secure IPv6 routing, apply IPv6 first-hop security (RA Guard, DHCPv6 Guard, ND inspection), and handle transition mechanisms. Treat every control you learn as something you must also be able to do for IPv6.

How much automation is on the CCIE Security lab?

Enough that you cannot ignore it. The blueprint calls out interacting with devices through REST APIs using basic Python, the JSON/XML/YAML encoding formats, and DNAC northbound API use cases. You are not expected to be a software engineer, but you should be able to read and write a basic Python script that hits a REST API, parse the response, and understand the data formats. On-box Python and Jinja2 templating are the most exam-adjacent skills to practice.

Key Takeaways

  • CCIE Security is two exams: the 350-701 SCOR qualifying written, then the eight-hour hands-on v6.1 practical lab. Both are required, and the lab is where execution under time pressure is tested.
  • The lab is weighted Perimeter Security 20%, Secure Connectivity and Segmentation 20%, Security Infrastructure 15%, Identity Management 25%, and Advanced Threat Protection and Content Security 20%, on a dual-stack network you must also automate.
  • PingLabz has lab-proven, capture-backed coverage of the VPN, ASA firewall, IOS ZBF, infrastructure-hardening, Layer 2 security, and IPv6 domains, all cross-linked from the pillar guides above.
  • The NGFW/FTD, ISE identity, and content-security domains are on the backlog and are listed honestly rather than linked, so every link on this page points to content that actually exists.
  • A study lab is only as good as its honesty about platform limits: know that asav is Active/Standby only, that WebVPN is gone on 9.17+, that ZBF needs a licensed cat8000v, and that a zero counter on virtual IOL can be an artifact rather than a bug.
  • Lab everything. Reading about a crypto map or a failover proves nothing; building it, breaking it, and reading the counters is the entire point of the CCIE.
Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to Ping Labz.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.