Exam objective 5.3 asks you to master centralised policy management and automation using FortiManager. This concept matters because real networks have dozens or hundreds of firewalls, and configuring each one by hand is slow, error-prone, and impossible to scale. For the NSE7 exam, you need to understand how FortiManager unifies policies, automates repetitive tasks, and reduces human error across an entire enterprise network.
Jump to a section
A simple way to picture Automation and Centralized Management
A restaurant kitchen is a high-pressure environment. The head chef controls every station, from the grill to the pastry section, to ensure every plate that leaves the kitchen meets the same standard.
Before automation and centralised management, each station worked independently. The grill cook decided the steak temperature; the pastry chef chose the dessert plating. Some plates were perfect, others were burnt, and the restaurant had no consistent recipe book. Customers never knew what they would get. The head chef had to walk between stations constantly, shouting corrections, slowing everything down.
Then the restaurant adopted a centralised recipe system. The head chef created one master recipe book that every station had to follow. She programmed the smart ovens to cook steaks at exactly 200°C for exactly 12 minutes. She set the plating templates on the digital screens above each pass. If a cook tried to deviate, the system alerted the head chef immediately.
This maps precisely to how FortiManager works. Instead of managing each firewall separately (like controlling each kitchen station by shouting), a network administrator uses FortiManager as the head chef's master console. Policies (recipes) are created once and pushed to every device. Automation stitches (smart oven programmes) trigger actions when specific conditions are met. The result is consistent security across the entire network, just like every plate now tastes the same. The network administrator no longer walks from firewall to firewall; they sit at one central dashboard and orchestrate everything.
Centralised policy management means controlling the security rules for many firewalls from a single point. Instead of logging into each firewall individually to change a rule, you make the change once in FortiManager, and it pushes that change out to every device automatically.
FortiManager acts as a central server that communicates with FortiGate firewalls. Think of FortiManager as the brain and each FortiGate as a hand. The brain decides the rules, and the hands execute them. This setup is called a hub-and-spoke model: FortiManager is the hub, and each FortiGate is a spoke.
Automation in FortiManager means you can define triggers and actions that happen automatically without human intervention. For example, if a firewall detects a malware attack, it can automatically send a log to FortiManager. FortiManager then runs an automation stitch, which is a sequence of steps. An automation stitch might block the malicious IP address on all firewalls, send an email alert to the security team, and create a ticket in the ticketing system.
Here is the key terminology you must understand for the exam:
Policy: a set of rules that determine which traffic is allowed or blocked. For example, "Allow HTTP traffic from the internal network to the internet."
Policy Package: a collection of policies grouped together for a specific purpose, such as "Branch Office Package" or "Data Center Package."
Device Group: a logical grouping of FortiGate firewalls that share the same policy package. For example, all branch office firewalls might be in one device group.
ADOM (Administrative Domain): a way to divide FortiManager into separate management domains, so different teams can manage different parts of the network without interfering with each other.
Automation Stitch: a trigger (like a log event or a schedule) and an action (like running a script or sending a message).
Why does this exist? Before centralised management, network administrators used a "sneaker net" approach. They would walk to each firewall, connect a laptop, log in, and manually type commands to change a rule. This was slow, and if one firewall received a slightly different rule, the network became inconsistent — some users had access they shouldnt, others were blocked from legitimately needed resources. Security gaps appeared.
Centralised management replaces this manual, error-prone process. FortiManager stores a master copy of all policies. When you make a change, it verifies the change before pushing it. If the change conflicts with another policy, FortiManager warns you. This is called policy consistency checking.
Automation replaces human reaction time. In a traditional setup, if a new threat appeared at 3am, a human might not see it until morning. Automation stitches can respond in milliseconds. For example, an automation stitch can be configured to monitor for specific log events, such as repeated failed login attempts. When the count exceeds a threshold, the stitch automatically blocks the source IP across all firewalls in the device group.
How does it work in practice? Let us break down the workflow: 1. An administrator creates a policy package in FortiManager. 2. The administrator assigns that policy package to a device group, which contains several FortiGates. 3. The administrator makes a change, such as adding a new rule to allow access to a new cloud application. 4. FortiManager checks the change for conflicts. If there are none, the administrator clicks "Install" or "Push." 5. FortiManager sends the updated policy package to each FortiGate in the device group. 6. Each FortiGate applies the new policies. 7. If a FortiGate is offline when the push happens, FortiManager queues the change and pushes it when the device comes back online.
This is why centralised management and automation are essential for modern enterprises. Without them, a network with 100 firewalls would require a full-time team just to maintain policies. With FortiManager, one or two administrators can manage thousands of devices effectively.
Create an ADOM for each tenant or department
Before managing devices, you must create an Administrative Domain (ADOM). This isolates the management environment. In FortiManager, each ADOM has its own policy packages, objects, and logs. For the exam, remember that different customers or departments should be in separate ADOMs to prevent accidental policy changes.
Add FortiGate devices to FortiManager and assign them to device groups
You register each FortiGate with FortiManager. Then you organise them into device groups. A device group is simply a collection of devices that share the same policy package. In the exam, you might be asked to troubleshoot why a policy change did not apply to one device — the answer is often that the device was not in the correct device group.
Create or edit a policy package and assign it to a device group
You define firewall policies (rules) in the policy package. For example, a policy might allow web traffic from the internal network to the internet. You then assign that policy package to the device group. Any device in that group will receive those policies. This is the core of centralised management: write once, apply to many.
Run a policy check to detect conflicts
Before installing, FortiManager can simulate the policy installation and check for conflicts. For example, if you add a policy that allows all traffic but there is already a policy that blocks all traffic, FortiManager will flag this. In the exam, they expect you to know that the policy check is a separate step from installation.
Install the policy package to the managed devices
Clicking 'Install' sends the policy package to all devices in the assigned device group. FortiManager uses a delta installation, meaning it sends only the changes, not the entire rule set. If a device is offline, the change is queued and will be installed when the device reconnects. This step is called the 'Install' or 'Push' operation.
Define an automation stitch for automatic threat response
You go to the Automation section in FortiManager and create a new stitch. You choose a trigger (e.g., when a log event shows a brute force attack). You optionally add a condition (e.g., only for devices in the branch office group). You then define one or more actions (e.g., block the IP address, send an alert email). This step is what enables automated security responses.
Consider a multinational retail company with 200 stores across Europe. Each store has a FortiGate firewall that connects back to the headquarters. The company's security policy requires that all store firewalls block access to certain malicious websites, allow only approved cloud services, and restrict access to the corporate network from store devices.
In the old way, a network administrator would have to manually connect to each store's firewall every time a policy changed. If a new malicious website was identified on Monday, the administrator would need to update 200 firewalls one by one. This could take days. By Wednesday, several stores would already be compromised.
With FortiManager, the administrator does this:
First, they log into the FortiManager central dashboard.
They navigate to the "Policy & Objects" section and select the policy package assigned to all store firewalls.
They edit the existing web filtering policy and add the new malicious website category to the blocked list.
They click "Install" and select the device group "Europe Stores".
FortiManager pushes the updated policy to all 200 firewalls simultaneously.
Within minutes, every store is protected against the new threat.
Now let us look at automation in a real-world context. Suppose the company's security team notices a pattern: cyberattacks often start with a brute force attempt on the store's VPN gateway. The attacks happen at night when the stores are closed. The security team wants to automatically block any IP address that attempts more than 10 failed VPN logins in 5 minutes.
They create an automation stitch in FortiManager:
The trigger is a log event: "Failed VPN login attempt from same IP address > 10 times in 5 minutes."
The condition is that the FortiGate detecting this must be a store firewall.
The action is to add the offending IP address to a block list that is active on all firewalls in the device group.
The administrator also adds a second action: send an email to the security team with the IP address and timestamp.
Once this automation stitch is enabled, the system runs 24/7. At 2am, a store's firewall detects 12 failed VPN attempts from an IP address in 4 minutes. The automation stitch triggers instantly. The IP address is added to the block list on all 200 store firewalls within seconds. The security team receives an email alert. By the time the human analyst reads the email at 8am, the threat is already neutralised.
This is what the NSE7 exam wants you to understand: automation is not just a nice-to-have; it is a critical layer of defence that operates faster than any human can. Centralised management is the foundation that makes automation possible across a large network. Without centralisation, each firewall would act in isolation, and an automation script running on one firewall would not know to block the same IP on another. FortiManager solves that by propagating actions across the entire device group.
The NSE7 exam (objective 5.3) specifically tests your ability to design and troubleshoot centralised policy management and automation on FortiManager. The questions are not about memorising GUI button names. They test your understanding of concepts, workflows, and common pitfalls.
Here are the exam topics you must master:
Policy package installation workflow: what happens when you install a policy package to a device that is offline? FortiManager queues the change. If the device remains offline for too long, the policy revision will be marked as "pending."
ADOMs: you must know that ADOMs allow multi-tenancy. Each ADOM is isolated, so policies from one ADOM cannot affect devices in another ADOM.
Device groups versus policy packages: a device group contains devices that share the same policy package. Changing the policy package assigned to a device group is a critical operation.
Automation stitch components: trigger, condition, and action. The exam will present a scenario and ask which component is missing or misconfigured.
Revision history: FortiManager keeps a history of every policy change. You can roll back to a previous revision. The exam may ask you to identify the correct steps for a rollback.
Conflict detection: before installing a policy, FortiManager checks for conflicts. A conflict could be two policies with overlapping conditions that contradict each other. The exam will present a conflict scenario and ask what FortiManager will do.
Common traps in the exam:
Trap: They give you a scenario where a policy change works on one firewall but not another. They want you to check if the policy package is assigned to the correct device group.
Trap: They describe an automation stitch that does not trigger. They want you to check if the log event trigger is correctly defined (e.g., the log severity level might be set wrong).
Trap: They ask about rollback. They will include a distractor that says "roll back from the firewall CLI" — wrong. The rollback must happen from FortiManager central revision history.
Trap: They confuse administrative access policies with firewall policies. Administrative access controls who can log into FortiManager; firewall policies control traffic flow.
Key definitions to memorise:
Policy Package: a container for firewall policies that is installed to one or more devices.
Device Group: a collection of devices that receive the same policy package.
ADOM: an administrative domain that isolates management between different tenants or departments.
Automation Trigger: the event that starts a stitch (log event, schedule, script output).
Automation Action: what the stitch does (run script, send email, add to dynamic block list).
Install: the process of sending a policy package from FortiManager to the managed devices.
Policy Check: the validation step FortiManager performs before installation to detect conflicts.
FortiManager centralises policy management so one change can be pushed to hundreds of firewalls simultaneously.
An automation stitch consists of a trigger, an optional condition, and one or more actions that execute automatically.
Device groups allow you to manage multiple firewalls as a single unit, all receiving the same policy package.
ADOMs provide complete administrative isolation, preventing one team from affecting another team's devices or policies.
Policy conflict detection in FortiManager warns you before installation if new rules contradict existing rules.
FortiManager queues policy changes for offline devices and pushes them automatically when the device reconnects.
Automation can respond to threats in milliseconds, far faster than a human operator can react.
Rolling back to a previous policy revision is done through FortiManager's revision history, not from the individual firewall's CLI.
These come up on the exam all the time. Here's how to tell them apart.
Centralised Policy Management
One policy change is pushed to all devices simultaneously
Policy consistency is guaranteed across the network
Takes seconds to apply a change to hundreds of firewalls
Decentralised (Per-Device) Management
Each firewall must be configured individually
Risk of inconsistency if a rule is accidentally skipped
Can take days to apply a change to a large fleet
Automation Stitch
Responds in milliseconds to a trigger event
Operates 24/7 without human fatigue
Can coordinate actions across multiple devices at once
Manual Response
Response time depends on when a human reads the alert
Prone to error if the human misses a step
Each action must be performed separately on each device
Policy Package
A collection of many firewall policies grouped together
Assigned to device groups, not individual devices
Managed and versioned centrally in FortiManager
Firewall Policy (Individual Rule)
A single rule that allows or blocks a specific type of traffic
Defined within a policy package
Cannot exist outside a policy package in FortiManager
ADOM
Provides full administrative isolation including logs and administrators
Used to separate different tenants or departments
An ADOM can contain multiple device groups
Device Group
A logical grouping of devices that share the same policy package
Does not isolate administrators or logs
Exists inside an ADOM
Mistake
FortiManager is just a backup tool for firewall configurations.
Correct
FortiManager is a central management platform that actively pushes policies, monitors compliance, and automates responses in real time.
Beginners see the ability to store configurations and assume it is only for backup, because backup is a familiar concept. They miss the active management and automation capabilities.
Mistake
An automation stitch can run on a single firewall without involving FortiManager.
Correct
An automation stitch is defined on FortiManager and can be executed on one or many FortiGates, but the central management is required to coordinate actions across multiple devices.
People familiar with local firewall scripting assume automation is purely a per-device feature. They dont realise FortiManager orchestrates actions across the fleet.
Mistake
If a FortiGate is offline, the policy change is lost and must be redone.
Correct
FortiManager queues the pending policy change and pushes it automatically when the FortiGate comes back online.
In everyday software, if a service is offline, updates often fail permanently. Beginners assume the same for network devices, but FortiManager is designed for unreliable connectivity.
Mistake
ADOMs are unnecessary; you can just use different policy packages for different teams.
Correct
ADOMs provide full isolation, including separate administrators, objects, and logs. Policy packages alone do not prevent one team from accidentally deleting another team's objects.
The term 'administrative domain' sounds abstract. Beginners think it is just another folder, so they underestimate its security and isolation role.
Mistake
Once a policy is installed on a device, you cannot change it without reinstalling the entire package.
Correct
You can make incremental changes to a policy package and install only the changes (delta installation). FortiManager sends only the differences, not the whole package.
This misconception comes from experience with older systems where any change required a full reload. Beginners dont know that modern systems optimise updates.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No. FortiManager is designed to manage only Fortinet devices, primarily FortiGate firewalls. It does not manage Cisco, Palo Alto, or other brands.
You can use the revision history in FortiManager to roll back to a previous version of the policy package. This will reinstall the older, correct policies on all affected devices.
FortiManager is available as a physical appliance, a virtual machine, or as a cloud-based service (FortiManager as a Service). You can choose the deployment that fits your network.
It depends on the model. Entry-level devices support tens of firewalls, while high-end models can manage thousands. Check the Fortinet datasheet for the specific model's limits.
A policy is the rule that decides what to do with traffic (allow or block). An object is a building block used in policies, such as an IP address, a service (like HTTP), or a schedule. You define objects once and reuse them across policies.
Yes. One type of trigger for an automation stitch is a schedule. You can set a stitch to run every hour, daily, or at a specific time. This is useful for tasks like generating reports or updating dynamic block lists.
You've finished Automation and Centralized Management. Continue through the NSE7 study guide to build a complete picture of the exam.
Done with this chapter?