Cisco ASA vs FTD for CCIE Security v6.1: Which Platform to Master First

Every CCIE Security v6.1 candidate hits the same question early in their prep: do I master ASA first, or dive straight into FTD?

Reddit threads are full of conflicting advice. Some candidates say FTD dominates the lab. Others insist ASA fundamentals are non-negotiable. The truth — as usual — is more nuanced than either camp admits.

I’ve spent significant time dissecting the v6.1 blueprint, lab reports from recent candidates, and the actual platform behaviors you’ll encounter under exam pressure. Here’s the definitive breakdown.

The v6.1 Blueprint Reality

Let’s start with what Cisco actually tells us. The CCIE Security v6.1 exam topics list both platforms explicitly:

• Section 2.0 — Perimeter Security and Intrusion Prevention (22%) covers ASA and FTD deployment, NAT, VPN, and high availability
• Section 3.0 — Secure Connectivity and Segmentation (19%) includes site-to-site and remote access VPN on both platforms
• Section 5.0 — Advanced Threat Protection and Content Security (12%) is heavily FTD/FMC territory

That’s roughly 53% of the lab where ASA and/or FTD knowledge is directly tested. But here’s what the blueprint doesn’t tell you: the balance between them has shifted dramatically from v6.0.

The Shift Toward FTD

In v6.0, ASA carried roughly equal weight to FTD. In v6.1, candidates consistently report that FTD tasks outnumber ASA tasks by approximately 2:1. FMC-managed FTD is the primary firewall platform in most lab scenarios.

This doesn’t mean ASA is irrelevant — far from it. But it means your study time allocation should reflect reality:

ASA: What You Need to Know Cold

ASA isn’t going away from the exam. Cisco knows that thousands of production networks still run ASA, and the platform tests fundamental security concepts that every expert should understand.

Deployment Modes

You’ll encounter ASA in two modes on the lab:

Routed Mode — the default and most common:

ciscoasa(config)# firewall transparent
ciscoasa(config)# no firewall transparent
ciscoasa(config)# show firewall
Firewall mode: Router

Transparent Mode — Layer 2 firewall, appears as a bump in the wire:

ciscoasa(config)# firewall transparent
ciscoasa(config)# show firewall
Firewall mode: Transparent

In transparent mode, you lose the routing capabilities but gain the ability to insert the ASA inline without readdressing. The lab loves testing whether you know when to use each mode and the behavioral differences.

Key transparent mode gotcha that catches candidates: you need a management IP on a BVI, and ARP inspection is enabled by default:

ciscoasa(config)# interface BVI 1
ciscoasa(config-if)# ip address 10.1.1.1 255.255.255.0
ciscoasa(config-if)# no shutdown

NAT on ASA: The Foundation

ASA NAT is where your fundamentals get tested hard. The exam expects you to configure NAT without hesitation — and to troubleshoot when it breaks.

Twice NAT (Manual NAT) — full control, processed in order:

! Static NAT for a web server
ciscoasa(config)# object network WEB-SERVER-REAL
ciscoasa(config-network-object)# host 10.1.1.100

ciscoasa(config)# object network WEB-SERVER-MAPPED
ciscoasa(config-network-object)# host 203.0.113.100

ciscoasa(config)# nat (inside,outside) source static WEB-SERVER-REAL WEB-SERVER-MAPPED

Auto NAT (Object NAT) — simpler, defined inside the object:

ciscoasa(config)# object network INSIDE-SUBNET
ciscoasa(config-network-object)# subnet 10.1.1.0 255.255.255.0
ciscoasa(config-network-object)# nat (inside,outside) dynamic interface

The critical distinction: Twice NAT is processed before Auto NAT (within each section — before/after auto). If your NAT isn’t working, check the processing order first:

1. Twice NAT (Section 1) — manual, before auto
2. Auto NAT — ordered by prefix length (most specific first)
3. Twice NAT (Section 3) — manual, after auto

ciscoasa# show nat
Manual NAT Policies (Section 1)
1 (inside) to (outside) source static WEB-SERVER-REAL WEB-SERVER-MAPPED
    translate_hits = 1523, untranslate_hits = 892

Auto NAT Policies (Section 2)
1 (inside) to (outside) source dynamic INSIDE-SUBNET interface
    translate_hits = 45210, untranslate_hits = 0

ASA Failover

ASA Active/Standby failover is a guaranteed lab topic. The configuration is straightforward but the troubleshooting can be tricky:

! Primary ASA
ciscoasa(config)# failover
ciscoasa(config)# failover lan unit primary
ciscoasa(config)# failover lan interface FAILOVER GigabitEthernet0/3
ciscoasa(config)# failover polltime unit 1 holdtime 5
ciscoasa(config)# failover key cisco123
ciscoasa(config)# failover link STATE GigabitEthernet0/4
ciscoasa(config)# failover interface ip FAILOVER 10.0.0.1 255.255.255.252 standby 10.0.0.2
ciscoasa(config)# failover interface ip STATE 10.0.0.5 255.255.255.252 standby 10.0.0.6

! Secondary ASA
ciscoasa(config)# failover
ciscoasa(config)# failover lan unit secondary
ciscoasa(config)# failover lan interface FAILOVER GigabitEthernet0/3
ciscoasa(config)# failover key cisco123
ciscoasa(config)# failover link STATE GigabitEthernet0/4
ciscoasa(config)# failover interface ip FAILOVER 10.0.0.1 255.255.255.252 standby 10.0.0.2
ciscoasa(config)# failover interface ip STATE 10.0.0.5 255.255.255.252 standby 10.0.0.6

The number one failover debugging command:

ciscoasa# show failover state
               State          Last Failure Reason
This host  -   Primary
               Active         None
Other host -   Secondary
               Standby Ready  None

If you see “Standby Cold” or “Failed,” check the failover link first — 90% of the time it’s a Layer 1/2 issue on the failover interface.

FTD: The New Reality

FTD (Firepower Threat Defense) is Cisco’s converged NGFW platform. It combines the ASA firewall engine with Snort IPS, URL filtering, malware detection, and AMP into a single image. For the CCIE Security lab, you’ll primarily manage FTD through FMC (Firepower Management Center).

FMC vs FDM: Know the Difference

FMC (Firepower Management Center) — centralized management for multiple FTD devices. This is what the lab uses 90% of the time.

FDM (Firepower Device Manager) — on-box management for standalone FTD. Limited features, simpler GUI.

The lab expects FMC proficiency. You need to navigate it fast — because FMC’s GUI has latency, and every click costs you time.

FTD Deployment Modes

FTD supports the same two fundamental modes, but the terminology and configuration differ:

Routed Mode — default, most common in the lab:

• FTD acts as a Layer 3 hop
• Full routing capabilities (OSPF, BGP, EIGRP, static)
• NAT and PAT processing

Transparent Mode — Layer 2 inline:

• Configured during initial setup or via FMC
• Bridge groups replace traditional interfaces
• Same BVI concept as ASA but configured through FMC GUI

Inline Set — unique to FTD, not available on ASA:

• FTD sits inline between two interfaces
• Traffic passes through without FTD being a routed hop
• Primarily for IPS/IDS inspection without network topology changes
• The lab sometimes tests this for specific IPS scenarios

NAT on FTD: The FMC Way

Here’s where candidates get burned. FTD NAT is conceptually identical to ASA NAT — same Twice NAT vs Auto NAT logic — but it’s configured through FMC’s GUI, and the terminology is slightly different.

Auto NAT in FMC:

1. Devices → NAT → select the FTD device
2. Add Rule → Auto NAT Rule
3. Select the network object and define the translation

Manual NAT (Twice NAT) in FMC:

1. Devices → NAT → select the FTD device
2. Add Rule → Manual NAT Rule
3. Define source original, source translated, destination original, destination translated

The processing order is identical to ASA:

1. Manual NAT (Section 1)
2. Auto NAT (Section 2)
3. Manual NAT (Section 3 — after auto)

Critical FMC workflow you must internalize: After configuring NAT (or any policy), you must deploy to the FTD device. Forgetting to click Deploy is the #1 time-waster I’ve seen candidates report.

FTD Access Control Policies

This is the core of FTD management and where the NGFW capabilities shine:

Access Control Policy (ACP) — the main traffic policy:

• Ordered rules evaluated top-down
• Each rule can specify: zones, networks, ports, applications, URLs, users
• Actions: Allow, Trust, Block, Monitor, Interactive Block

Prefilter Policy — evaluated BEFORE the ACP:

• Uses traditional 5-tuple matching (like ASA ACLs)
• Much faster because it bypasses Snort inspection
• Use for trusted traffic that doesn’t need deep inspection

Lab tip: Use Prefilter rules for high-volume trusted traffic (like management traffic or backup streams). This reduces Snort load and can prevent performance issues during the lab that cause timeout failures on verification.

FTD VPN Configuration

VPN on FTD through FMC is one of the most time-consuming lab tasks because of the multi-step GUI workflow:

Site-to-Site VPN:

1. Devices → VPN → Site to Site → Add VPN
2. Define topology (Point to Point or Hub and Spoke)
3. Configure IKE settings (IKEv1 or IKEv2)
4. Configure IPsec proposals
5. Define protected networks
6. Deploy

Remote Access VPN (RAVPN):

1. Devices → VPN → Remote Access → Add
2. Select authentication method (AAA, certificates, both)
3. Configure connection profiles
4. Define group policies
5. Configure address pools
6. Deploy

The deploy step after each change is what kills your time. Batch your VPN changes — configure everything, verify in the GUI, then deploy once.

Head-to-Head: ASA vs FTD for Key Lab Tasks

The pattern is clear: ASA is faster to configure, FTD is more capable. The lab tests both — ASA for speed and fundamentals, FTD for advanced NGFW features.

The Study Order That Works

Based on the v6.1 blueprint weight and platform dependencies, here’s the order I recommend:

Phase 1: ASA Fundamentals (Weeks 1-3)

Start with ASA even though FTD carries more lab weight. Why? Because FTD’s firewall engine IS the ASA engine. Understanding ASA NAT, ACLs, and VPN from the CLI gives you the conceptual foundation that makes FMC configuration intuitive instead of magical.

Week 1: Deployment modes, interfaces, security levels, basic ACLs Week 2: NAT (Auto NAT, Twice NAT, NAT order of operations, identity NAT) Week 3: Failover (Active/Standby, Active/Active), VPN (site-to-site IKEv1/v2)

Phase 2: FTD/FMC Core (Weeks 4-7)

Now transition to FTD. Your ASA knowledge translates directly.

Week 4: FMC navigation, device registration, platform settings, interface configuration Week 5: Access Control Policies, Prefilter policies, Security Intelligence Week 6: NAT on FTD (map your ASA NAT knowledge to the FMC GUI), FTD HA Week 7: VPN on FTD (site-to-site, RAVPN), certificate management

Phase 3: Advanced FTD Features (Weeks 8-10)

The NGFW capabilities that only exist on FTD:

Week 8: Snort IPS policies, custom rules, variable sets Week 9: Malware/AMP policies, file policies, URL filtering Week 10: FTD integration with ISE (pxGrid), identity-based access control — our CCIE Security v6.1 ISE lab prep guide covers the ISE side in detail

Phase 4: Speed Labs (Weeks 11-12)

Timed practice combining both platforms:

• Configure ASA failover pair + FTD/FMC pair in the same topology
• Build VPN between ASA and FTD (interoperability scenario)
• Troubleshoot broken configs on both platforms under time pressure
• Practice the FMC deploy workflow until it’s muscle memory

The FMC Speed Problem (and How to Beat It)

Every candidate complains about FMC being slow. The GUI has inherent latency — page loads, deploy cycles, and the occasional “please wait” spinner that eats 30 seconds of your life.

Here’s how to minimize the damage:

1. Pre-Build Your Object Library

Before touching any policies, create all your network objects, port objects, and interface groups first. When you start building ACPs and NAT rules, you’ll select from existing objects instead of creating them inline (which triggers additional page loads).

2. Batch Your Deploys

Never deploy after a single change. Configure all related changes (NAT + ACP + VPN for a given requirement), verify in the GUI, then deploy once. Each deploy cycle takes 30-90 seconds depending on the change scope.

3. Use the FMC CLI When Possible

FMC has a diagnostic CLI. For troubleshooting, SSH into the FTD device and use:

> system support diagnostic-cli
ciscoasa# show nat
ciscoasa# show xlate
ciscoasa# show conn
ciscoasa# show access-list

Yes, that’s the ASA CLI running underneath FTD. Your ASA troubleshooting skills transfer directly.

4. Know Your Keyboard Shortcuts

FMC doesn’t have many, but the browser does:

• Ctrl+F to search within long policy lists
• Tab to move between fields quickly
• Enter to submit dialogs instead of clicking Save

These seem trivial. They save 10-15 minutes over an 8-hour lab.

Common Pitfalls on Exam Day

Pitfall 1: Forgetting to Deploy

I cannot stress this enough. You configure a perfect NAT rule in FMC, move to the next task, and wonder why traffic isn’t flowing. The rule exists in FMC’s pending changes — it’s not on the FTD device yet. Deploy after every logical block of changes.

Pitfall 2: NAT Order Confusion

You built the same NAT logic on ASA and FTD, but one works and the other doesn’t. Check the rule ordering. FMC’s NAT rule table doesn’t always display in processing order by default — make sure you’re looking at the actual Section 1/2/3 placement.

Pitfall 3: Security Zone Mismatch

FTD uses Security Zones instead of ASA’s security levels. A common error: you create an ACP rule allowing traffic from “inside-zone” to “outside-zone,” but the FTD interfaces aren’t assigned to those zones. Always verify zone assignments under Devices → Device Management → Interfaces.

Pitfall 4: IKEv1 vs IKEv2 Platform Defaults

ASA defaults to IKEv1 for site-to-site VPN. FTD defaults to IKEv2. If you’re building a VPN between them and don’t explicitly match versions, the tunnel won’t come up — and the error messages won’t clearly tell you why.

Pitfall 5: ASA Syslog vs FTD Events

When troubleshooting ASA, you rely on syslogs (show logging). On FTD, you use FMC’s Analysis → Connection Events. Different tools, same troubleshooting logic — but knowing which tool to reach for on each platform saves critical minutes.

Resource Stack for ASA vs FTD Prep

Here’s what actually works, based on candidate feedback:

The Bottom Line

For CCIE Security v6.1:

1. Learn ASA first — it’s the conceptual foundation and the faster platform for basic tasks
2. Spend more time on FTD — it carries more weight in the v6.1 lab
3. Master the FMC workflow — deploy cycles, object management, and ACP construction
4. Practice interop scenarios — ASA-to-FTD VPN tunnels, mixed environments
5. Build speed on FMC — pre-built objects, batched deploys, diagnostic CLI

The candidates who struggle aren’t the ones who don’t know the technology. They’re the ones who can’t execute fast enough in FMC. Time management on FTD tasks is the single biggest differentiator between passing and failing. If you’re mapping out your full Security track timeline, see our CCNP to CCIE Security realistic study plan.

Frequently Asked Questions

Should I learn ASA or FTD first for CCIE Security v6.1?

Start with ASA. FTD’s firewall engine is built on ASA, so understanding ASA NAT, ACLs, and VPN from the CLI gives you the conceptual foundation that makes FMC configuration intuitive. Then shift 55-60% of your firewall study time to FTD.

How much of the CCIE Security v6.1 lab is FTD vs ASA?

Candidates consistently report FTD tasks outnumber ASA tasks by approximately 2:1 in v6.1. About 53% of the total lab directly tests ASA and/or FTD knowledge, with FMC-managed FTD as the primary firewall platform.

What is the biggest time waster in the CCIE Security lab?

Forgetting to deploy changes in FMC. Every configuration change in FMC sits in pending state until you explicitly deploy it to the FTD device. Batch your changes and deploy after each logical block to save time.

Can I use CLI on FTD during the CCIE Security lab?

Yes. FTD has a diagnostic CLI accessible via SSH that runs the ASA engine underneath. Commands like show nat, show xlate, and show conn work directly, so your ASA troubleshooting skills transfer to FTD.

How long should I study for the CCIE Security v6.1 firewall sections?

Plan for 12 weeks focused on firewalls: 3 weeks on ASA fundamentals, 4 weeks on FTD/FMC core, 3 weeks on advanced FTD features like Snort IPS and ISE integration, then 2 weeks of timed speed labs combining both platforms.

Ready to fast-track your CCIE journey? Contact us on Telegram @phil66xx for a free assessment.