Cisco FTD and FMC — Platform Overview

Overview

Cisco’s Next-Generation Firewall story went through a confusing middle chapter before arriving at its current form. For several years, enterprises ran an ASA with a FirePOWER module — a traditional stateful firewall with a bolted-on intrusion prevention engine. The two ran as separate processes, required separate management consoles, and had limited integration between their policy engines.

Firepower Threat Defense (FTD) resolved this by combining the ASA stateful firewall engine and the Snort-based FirePOWER services into a single unified image with a single policy model. FTD is not ASA plus FirePOWER as two processes side by side — it is a new OS that incorporates both into a cohesive platform. The management interface, the deployment model, and the policy architecture are all different from the legacy ASA.

Firepower Management Center (FMC) is the centralised management platform for FTD devices. It is the control plane for the entire FTD fleet — the system where policies are authored, devices are configured, events are collected, and reports are generated. Understanding the FMC ↔ FTD relationship is the first step to understanding how the Firepower platform functions as a whole.

FTD vs ASA vs ASA with FirePOWER

The ASA with FirePOWER is the legacy hybrid. FTD replaced it on all new hardware starting with the Firepower 2100 and 4100 series. On older ASA 5500-X hardware, FTD can be installed as a replacement image, though some features differ from native FTD hardware.

FTD Hardware Platforms

Cisco offers FTD across a wide range of hardware designed for different performance tiers:

The Firepower 1100 and 2100 series run a simplified form of the chassis OS (FXOS lite) that does not require separate chassis manager interaction for day-to-day operations. The 4100 and 9300 series use the full FXOS chassis, which introduces a two-layer management model described later.

FMC Deployment Options

FMC can be deployed as physical hardware or as a virtual appliance:

For most new deployments, FMCv on a VMware or cloud platform is the preferred choice because it avoids dedicated hardware, supports snapshots for backup, and scales with the virtualisation infrastructure.

Management Options for FTD

Three management options exist for FTD. Only one can be active at a time for a given device:

A device cannot be simultaneously managed by FMC and FDM. Switching between management modes requires a factory reset.

FMC ↔ FTD Communication

FMC and FTD communicate over a dedicated management channel:

• FTD has a dedicated management interface (a separate physical port from the data-plane interfaces). This interface is used exclusively for FMC communication, software updates, and health monitoring.
• The channel is an SSL/TLS encrypted connection initiated by FTD toward FMC during registration.
• Traffic carried over this channel includes: policy deployments, event data (connection events, intrusion events, file events), health status, and software image transfers.

Registration Process

On FTD CLI (via console or SSH to management interface):
  configure manager add <FMC-IP-or-hostname> <registration-key>

On FMC GUI:
  Devices → Device Management → Add → Add Device
  Enter: FTD IP address, registration key, initial ACP, device group

The registration key is a shared secret used once to authenticate the FTD to FMC. After registration, the SSL channel takes over and the key is no longer used. The FTD becomes visible in FMC’s device inventory and is ready to receive policy deployments.

Policy Deployment Workflow

Changes in FMC do not take effect until they are explicitly deployed to devices. This is by design — it allows an operator to stage multiple related changes (update the ACP, modify a NAT rule, adjust an IPS policy) and push them as a single atomic deployment.

The workflow:

1. Make changes in FMC GUI (policy edits, object updates, interface configuration)
2. FMC displays a “X changes pending” banner in the top navigation bar
3. Click Deploy, select the target devices, review the pending changes summary
4. FMC validates the configuration for consistency errors
5. FMC pushes the compiled policy to each selected FTD device
6. Devices apply the new configuration — no reboot required for policy changes

Any out-of-band changes made directly on the FTD CLI will be overwritten the next time a full policy deployment occurs from FMC. The FTD is designed to be managed entirely through FMC; direct CLI modification is supported only for troubleshooting and initial setup.

FXOS Chassis Manager (4100/9300 Series)

The Firepower 4100 and 9300 series use a two-layer architecture:

Layer 1 — FXOS (Firepower eXtensible Operating System): manages the physical chassis — hardware health, interface assignment, security module configuration, inter-blade communication, and software installs.

Layer 2 — Logical Device (FTD): the FTD instance running on top of FXOS. Each chassis can run one or more FTD instances (multi-instance mode on 4100/9300).

The Firepower 9300 is modular: it accepts up to three security module blades (SM-24, SM-36, SM-44, or SM-56). Each blade can host an independent FTD instance, managed separately by FMC.

To configure a 4100/9300:

1. Access the FXOS chassis manager (FCM) via HTTPS to the chassis management IP, or via the FXOS CLI
2. Assign physical interfaces to the logical FTD device
3. Install the FTD logical device on the chassis
4. Register the FTD logical device to FMC as normal

Security Zones

Security zones are logical groupings of interfaces used as match criteria in Access Control Policy rules, NAT rules, and identity rules. Before writing any ACP rules, the standard practice is to define zones that reflect the security posture of each network segment:

• outside-zone: internet-facing interfaces
• inside-zone: internal LAN interfaces
• dmz-zone: demilitarised zone for public-facing servers
• vpn-zone: VPN termination interfaces

An ACP rule that says “allow HTTP from inside-zone to outside-zone” applies to any interface that belongs to either zone, regardless of how many physical interfaces are involved. Zones abstract the policy from interface-level specifics and make it portable across deployments.

Interface Modes

FTD interfaces can operate in several modes depending on how the device is deployed:

Routed mode is the most common deployment for a perimeter firewall. Transparent mode is used when inserting FTD into an existing network without renumbering. Inline and passive modes are more common for IPS-only deployments inside the network.

Management Interface vs Data Interfaces

A frequent source of confusion is the distinction between the FTD management interface and data interfaces:

• Management interface (dedicated physical port, labelled Management0/0 or similar): out-of-band; carries FMC ↔ FTD communication only; never carries user traffic; should be on a dedicated management network
• Data interfaces (GigabitEthernet0/0, GigabitEthernet0/1, etc.): carry user traffic through the firewall; can optionally be configured to also accept SSH/HTTPS management access (called “on-data-plane management”)

Best practice is to keep the management interface on a dedicated management VLAN or network, isolated from user traffic, so that FMC communication is never dependent on the firewall’s own data-plane health.

FTD Licence Tiers Recap

All licences above Base require Smart Licensing and are consumed from the CSSM virtual account when assigned to a device via FMC.