FortiManager policy packages and administrative domains are the core tools for turning many FortiGate appliances into one governable policy system. The current certification context is Fortinet NSE 6 – FortiManager 7.6 Administrator; Fortinet replaced the older NSE 5/FCP-aligned FortiManager exam on July 15, 2026. The technical work remains focused on ADOM structure, policy packages, shared and per-device objects, revisions, workspace controls, installation targets, and synchronization between FortiManager’s databases and managed FortiGates.
A centralized manager creates leverage. A good change can reach hundreds of devices consistently, but a bad shared object or overly broad package can do the same. The purpose of design is therefore to make scope visible before installation. The internal overview of FortiManager features and benefits is useful background; this article focuses on the policy architecture operators need once centralized management is already in place.
The central question is always scope: what changes, where it changes, who approved it, and how operators will prove the result.
Treat ADOMs as governance boundaries
An ADOM separates devices, policy, objects, and delegated administration. Use it when there is a meaningful boundary such as tenant, business unit, environment, region, or FortiOS compatibility requirement. Avoid creating an ADOM for every small team or site because excessive partitioning duplicates policy and makes enterprise-wide changes harder.
Decide who can administer each ADOM and whether they need read-only, policy, device, or broader permissions. Least privilege matters because FortiManager changes can affect many firewalls at once. ADOM-level delegation also improves accountability by keeping unrelated administrators out of each other’s operational scope.
Document how devices move between ADOMs and what happens to associated policy and objects. Reorganization is normal in long-lived environments, so a boundary should be manageable through mergers, ownership changes, and platform upgrades.
ADOM versioning is part of the boundary decision. When a newer FortiOS feature is introduced, confirm that the ADOM version supports the targets and that older devices will not receive incompatible configuration. Version upgrades of the management domain should be planned like any other platform change because they influence what policy and objects can be represented.
Design policy packages around common intent
A policy package is a set of firewall and related policies that can target one or more devices or VDOMs. Group targets that share the same security intent. If two branches require nearly identical policy except for local subnets, use mappings or variables rather than cloning the package and allowing the copies to drift.
Multiple packages in one ADOM are useful when genuinely different rulebases exist, such as branch, data-center, or partner environments. Package count should follow policy differences, not organizational preference for separate folders.
Name packages for their operational role and keep ownership clear. The next administrator should understand which devices receive the package, what layer of policy it controls, and which team approves changes.
Policy packages should also be sized for reviewability. A package with thousands of unrelated rules can technically be centralized but still be difficult to reason about. Use sections, naming conventions, and clear ordering so reviewers can locate internet access, inter-zone, management, partner, and exception rules without scanning the entire table.
When several packages share a common service, keep the common object definitions aligned even if the rule order differs. Teams should avoid creating near-identical local objects with slightly different names because later troubleshooting becomes a search for which duplicate was installed to which device. Centralization should reduce semantic duplication, not move it into a larger database.
Use shared objects without creating hidden blast radius
Central objects reduce duplication, but shared scope makes edits consequential. Before changing an address group, service group, security profile, or certificate object, check every policy and package that references it. A small edit to one object can alter the effective access of many sites.
Per-device and dynamic mappings are useful when one logical object represents different local values. They preserve a common policy while allowing site-specific addressing. Validate that every target has the required mapping before installation.
Object hygiene matters. Duplicate names, stale objects, and ambiguous groups make reviews harder. Use FortiManager tools for unused or duplicate objects and remove clutter through normal change control rather than allowing the policy database to become an archaeological record.
Shared objects benefit from an ownership model. Network teams may own address ranges, security teams may own inspection profiles, and application teams may request service groups. Clarifying who approves changes prevents a central object database from becoming a place where anyone can modify a dependency used by everyone.
Understand global policy and local policy layers
Organizations sometimes need rules that apply across many ADOMs, such as baseline deny controls or enterprise-wide security requirements. Global policy packages can provide common header or footer policy that is assigned into ADOM policy packages. This is powerful because it enforces consistency above local policy design.
Keep global policy small and intentional. A broad rule at the global layer can affect every delegated team and may be harder for local operators to diagnose. Use global rules for requirements that truly are global, not as a shortcut for normal shared policy.
Document evaluation order so local teams know where their rules sit relative to global header and footer rules. Central governance works only when delegated administrators can predict the effective policy.
Global policy should be tested against at least one representative ADOM before broad assignment. Differences in local objects, interfaces, and package structure can produce surprises. Treat global layers as code with a large blast radius: small, reviewed, versioned, and deployed in controlled stages.
Use workspace, locking, and revisions to control concurrent change
FortiManager can use workspace or workflow modes that control how administrators lock and modify ADOM configuration. Choose a collaboration model that matches team size and risk. Without coordination, two administrators can make individually valid changes that interact poorly when installed together.
Create revisions at meaningful checkpoints, especially before large package installations or object refactoring. Revisions give operators a known state to compare and, where appropriate, restore. A revision is not a substitute for testing, but it greatly improves change traceability.
The wider discipline resembles configuration-management practice: successful configuration management depends on controlled edits, a known desired state, and an auditable path from intent to deployment.
Workspace locks should not be held indefinitely. Long locks can block urgent work and tempt administrators to bypass governance. Establish norms for lock duration, naming, and abandoned sessions, and use workflow approval only where it adds meaningful control rather than making every routine edit unnecessarily slow.
Preview installation scope before every significant push
FortiManager maintains databases that may differ from the running FortiGate configuration. The install process reconciles those states. Use the install preview to see which policy, objects, and device settings will change instead of assuming that only the item you just edited is affected.
Check installation targets carefully. A package can be assigned to multiple devices, and individual policies can have target restrictions. Confirm the target list before a production push, particularly when the same package serves test and production branches.
If the preview contains unexpected removals, changed interfaces, or unrelated objects, stop and explain them. A successful install of an unexpected change is still a failed change process.
Schedule installs when operational teams can validate the affected services. Even when FortiManager reports success, application tests, routing state, and device health should confirm the outcome. A central push can be syntactically correct while a site-specific mapping or dependency causes a real outage.
For high-risk changes, compare the installation preview with a peer-reviewed change plan before approval. The reviewer should be able to map each significant delta to an intended business or security requirement. Unexpected differences are easier to resolve before the push than during an outage when the same diff becomes evidence.
Keep device-level exceptions visible and temporary
Central policy inevitably encounters exceptions: a site with a legacy application, a partner address range, or a regulatory requirement. Represent exceptions explicitly and narrowly. Avoid copying the entire package just to accommodate one rule because the copy will diverge from future shared improvements.
Give exceptions an owner and review date. A temporary service opening that remains for years is technical debt and often a security exposure. Comments, naming conventions, and external change records should make the rationale easy to find.
Where possible, place exceptions near the related policy and keep the match criteria specific. An exception should not become a bypass for unrelated traffic simply because it is easier to maintain.
Exception inventory should be reviewed as part of application retirement. When a legacy system is decommissioned, remove the associated rule, service object, address group, and special security-profile adjustment together. Otherwise the visible application disappears while the access path remains available for future misuse.
Reconcile local changes and manager state deliberately
Administrators sometimes make emergency edits directly on a FortiGate. Once FortiManager is authoritative, those local changes create out-of-sync state. Decide in advance whether emergency edits will be imported into FortiManager, recreated centrally, or overwritten after the incident.
Retrieve and compare configuration rather than blindly pushing the manager database over an unknown local state. The goal is to preserve necessary emergency fixes while returning to one source of truth.
Limit who can make local changes on managed devices and log those actions. Central management loses much of its value when every site can silently diverge.
Out-of-band changes are especially risky during incidents because urgency reduces documentation. Use a simple emergency procedure: record the local command or GUI change, capture the pre-change state, restore service, then reconcile the exact delta into FortiManager before the incident is closed.
Audit policy packages as living security controls
Review hit counts, unused rules, broad services, disabled rules, stale objects, and duplicate policy. Combine technical evidence with application ownership so that cleanup does not remove a rarely used but critical disaster-recovery path.
Periodically test policy from representative sites and confirm that logging, security profiles, and NAT behavior match the intended design. The rule database may look clean while routing or object mappings create unexpected behavior on a particular device.
The Fortinet certifications portfolio continues to evolve, but FortiManager policy governance rests on durable principles: define administrative boundaries, reuse intent without hiding scope, preview changes, preserve revisions, and make exceptions explicit enough that a future operator can tell why they exist.
Metrics can help prioritize cleanup. Track the number of shared-object exceptions, policies with overly broad services, devices out of sync, failed installations, and emergency local changes. The purpose is not to reward a low rule count; it is to identify where governance or architecture is producing repeated operational risk.
A quarterly policy review can combine technical and business evidence: rule hits, application owner confirmation, ticket history, exception age, and platform health. This prevents “unused” from being the only cleanup criterion and keeps the review focused on whether the package still represents the organization’s current access model.