Managing FTD with FMC — Objects, Policy Hierarchy & the Deploy Workflow

① Register a device to FMC — registration key, NAT-ID and the sftunnel

Before FMC can manage an FTD, the two must trust each other. On the device you point it at the manager (set the FMC as its manager) with a shared registration key; in FMC you add the device using the device IP and the same key. The key is a one-time shared secret that bootstraps trust — it is not the ongoing password.

When there is NAT between FMC and the device — common when the firewall is behind another device or you do not know one sides routable IP — you also supply a matching NAT-ID on both ends. The NAT-ID lets the two sides recognise each other when an IP cannot be trusted as the identifier.

Once matched, FMC and the device build the sftunnel — an encrypted management channel on TCP 8305. From then on, all config pushes and event/log traffic flow inside that tunnel. If 8305 is blocked or the tunnel drops, management stops even though the firewall keeps passing traffic.

② Objects and the policy hierarchy — define once, reuse everywhere

FMC is built on reusable objects: a network object, a port object, a URL object, a security-zone object, and object groups that bundle them. You define the HR subnet or the corporate web ports once as an object, then reference it in every rule. Change the object and every rule that uses it updates — no hunting through dozens of ACEs.

The policy hierarchy you must name

On top of objects sit the policies, assigned to devices: platform settings (time, SSH, SNMP, logging), the access control policy (the master rule set), the intrusion policy and file/malware policy (invoked by Allow rules for Snort inspection), the NAT policy, and VPN policies. The access control policy is the spine; the others hang off it or are applied alongside it.

The interview line: objects are the vocabulary, policies are the sentences, and a device only gets the policies you assign to it.

③ The Deploy workflow — pending changes, deploy, preview and rollback

Here is the idea that trips people up: editing in FMC does not change the firewall. Your edits become pending changes — staged in FMC, flagged on the deploy badge — and the device keeps running its last deployed config until you act.

When you are ready you open Deploy, see which devices have pending changes, optionally preview the exact diff that will go down, then deploy to selected devices (not necessarily all of them). FMC validates the changes first; if validation fails, nothing is pushed. A successful deploy job sends the config over the sftunnel and the device applies it.

When a deploy goes wrong

If a deployment causes a problem, FMC can roll back a device to its previous deployed configuration. That makes Deploy a controlled, reversible change — stage, preview, deploy to a subset, verify, and roll back if needed — instead of a risky live edit.

④ Domains for multi-tenancy & Smart Licensing in CSSM

One FMC can be carved into Domains for multi-tenancy. There is always a Global domain, and you can create subdomains so different teams or customers manage only their own devices and policies, with admin scoped to their domain. One appliance, cleanly separated tenants.

Licensing is Smart Licensing. FMC registers to a Smart Account in CSSM and draws entitlements from a shared pool: an Essentials base license per device, plus add-on entitlements — IPS/Threat (intrusion + Snort), URL (URL filtering), and Malware (file/malware). You assign the entitlements a device actually needs; FMC tracks compliance.

Finally, FMC gives you health monitoring — a dashboard of device status, sftunnel/management connectivity, deploy results and resource alerts — so you see a device or tunnel problem before a change window does.