Administrative domains, or ADOMs, are one of the most important FortiManager design concepts because they decide where devices, policy packages, objects, administrators, and operational responsibility are separated. An ADOM is not merely a folder. It creates a management scope with its own policy and object database, its own device membership, and permissions that can be delegated to different administrators.
For the NSE 6 FortiManager 7.6 Administrator, the practical question is not simply what an ADOM is. You need to understand why an organization would create several ADOMs, how normal and backup modes differ, and how ADOM design affects policy installation, configuration revisions, administrator access, and multi-tenant operations.
ADOMs separate management scope, not network traffic
An ADOM creates an administrative boundary inside FortiManager. Devices placed in one ADOM are managed through that ADOM’s policy packages, objects, revisions, and administrative context. This is useful when a company has different business units, geographic regions, customers, or operational teams that should not all work inside the same management database.
The separation is a management construct. It does not automatically create packet-level isolation between customer or department networks. Network segmentation is still enforced on the managed FortiGate devices through interfaces, VDOMs, routing, firewall policy, VPNs, and other controls. Treating an ADOM as if it were a replacement for those data-plane boundaries can create a dangerous design misunderstanding.
ADOMs also help limit administrative blast radius. If an administrator is permitted to work only in a specific ADOM, the FortiManager interface can be scoped so that unrelated customer or business-unit devices are not part of that administrator’s normal working set. This is one reason ADOM design is central to managed-service and large-enterprise deployments.
Normal-mode ADOMs are read-write management domains
Fortinet defines a normal-mode ADOM as read-write. FortiManager can make changes to managed devices from this domain, maintain the device database, and install policy packages and configuration changes. The FortiGate reports configuration differences to FortiManager through the management relationship, allowing the manager to detect and reconcile out-of-band changes.
Normal mode therefore fits the common centralized-management model: administrators are expected to make controlled changes in FortiManager and then install those changes to FortiGate targets. Policy packages, shared objects, device settings, revisions, and install workflows all make sense because FortiManager is intended to be an active source of configuration.
This model also creates an operational expectation. If local administrators frequently change the FortiGate directly, FortiManager can detect that the device database and the real device differ. Teams need a clear authority model for where changes should originate or they will spend time reconciling configuration drift instead of managing policy.
Backup-mode ADOMs preserve configurations without full centralized control
Backup mode has a different purpose. Fortinet describes backup-mode ADOMs as a place to store managed-device configurations. FortiManager cannot directly push ordinary configuration changes from the normal GUI workflow in the same way it does in a normal-mode ADOM. Device configuration is primarily changed on the FortiGate itself, or with direct scripts where appropriate, and FortiManager maintains revisions for backup and visibility.
This makes backup mode useful when an organization wants centralized configuration history and oversight without moving full change authority into FortiManager. It can also help during staged adoption: operations may begin by collecting and reviewing configuration revisions before later standardizing policy and device management.
Backup mode is not a weaker version of normal mode that should be selected casually. The choice changes the management operating model. If a team expects FortiManager to own policy packages and perform routine installs, normal mode is the natural fit. If the requirement is mainly configuration retention and review, backup mode may be appropriate.
Do not confuse ADOM mode with ADOM device mode
FortiManager uses similar terminology for a separate setting: ADOM device mode can be Normal or Advanced. This is different from the normal-versus-backup ADOM operation mode. Device mode controls how FortiGate devices and their VDOMs can be distributed across ADOMs.
In normal ADOM device mode, a FortiGate belongs to a single ADOM. In advanced device mode, individual VDOMs from the same FortiGate can be assigned to different ADOMs. That flexibility is valuable in some service-provider and multi-tenant designs, but Fortinet warns that it makes management more complicated.
The distinction matters because many exam and production mistakes come from remembering the word “normal” without remembering which setting it describes. Ask two separate questions: is this ADOM read-write or backup-oriented, and can this device’s VDOMs be split across ADOMs? Those are different design decisions.
Multi-tenancy requires a deliberate boundary model
In a multi-tenant design, start with the unit that must have independent policy ownership and administrative visibility. A managed service provider may use one ADOM per customer. A large company might separate regulated environments, regions, or business units. The right boundary is the one that keeps policy ownership and change responsibility understandable.
Too few ADOMs can create crowded policy databases and overly broad administrator access. Too many ADOMs can make shared operations harder because every domain has its own devices, policy context, revisions, and lifecycle. The goal is not maximum isolation inside FortiManager; it is enough isolation to match the organization’s real operational boundaries.
Role-based access should follow the same model. Give administrators access to the ADOMs and functions they actually need rather than relying on naming conventions to prevent accidental changes. The wider Fortinet certification ecosystem repeatedly emphasizes centralized administration because safe scale depends on both product capability and disciplined delegation.
Version alignment affects what an ADOM can manage
FortiManager ADOMs are also associated with FortiOS versions. That matters because policy objects and device features change across FortiOS releases. When managed devices move to a newer supported FortiOS version, the ADOM database may also need to be upgraded so that FortiManager understands the corresponding object model and configuration syntax.
Do not plan an ADOM only around organizational structure and ignore software lifecycle. A customer with devices on a significantly different FortiOS release may need separate upgrade sequencing or a different ADOM strategy until versions converge. Current compatibility should be checked before moving devices or changing ADOM versions.
This is especially important during large upgrades. A FortiManager upgrade, an ADOM database upgrade, and a FortiGate upgrade are related but not interchangeable steps. Operators should understand the compatibility matrix and recovery path before changing all three layers in the same maintenance window.
Common ADOM mistakes reveal the design model
A device placed in the wrong ADOM may appear administratively isolated from the policy packages and objects intended for it. A backup-mode ADOM can surprise an administrator who expects ordinary centralized installs. Advanced device mode can surprise a team that assumes a physical FortiGate must be managed as one indivisible unit.
Another common mistake is to use ADOMs as a substitute for naming and ownership standards. Separate domains reduce overlap, but administrators still need predictable policy-package names, device groups, change comments, and revision practices. Otherwise each ADOM becomes a small version of the same operational confusion.
Legacy material may still refer to older FCP-era naming. The existing FortiManager 7.4 Administrator material is useful historical context, but the current exam level is NSE 6 and the product target is FortiManager 7.6. Preserve the architectural concepts while using current certification language.
A practical ADOM design workflow
Start by listing the independent administrative groups, device populations, FortiOS versions, and policy owners. Decide which groups genuinely require separate policy databases and permissions. Then decide whether each ADOM should operate in normal or backup mode and whether advanced device mode is actually necessary.
After the structure is created, test administrator profiles with real accounts, not only a super-admin account. Confirm that each operator can see the devices and policy objects they should manage and cannot see unrelated tenants. Add a small number of devices first, establish revision and install procedures, and then scale the design.
The strongest ADOM design is easy to explain: who owns this domain, which devices belong to it, which FortiOS generation it represents, how changes are made, and what administrators are allowed to do. If those answers are unclear, adding more ADOMs will not solve the underlying governance problem.
Moving devices between ADOMs should be treated as a migration, not a cosmetic reorganization. The destination ADOM must support the device and FortiOS version, and administrators should understand what happens to policy assignments, objects, revisions, and permissions after the move. Capture the current state and validate the destination design before relocating production devices.
Managed-service environments also need a repeatable tenant-onboarding process. Create the ADOM, set the intended mode and version, apply the correct administrator profiles, add or authorize devices, and validate visibility with a non-super-admin account. Consistency matters more as the number of tenants grows because a one-off exception becomes difficult to remember months later.
Shared operations should be documented outside the ADOM boundary as well. Backup schedules, FortiManager HA, administrator recovery, licensing, and platform upgrades affect every tenant even when policy databases are separated. Multi-tenancy reduces configuration overlap; it does not eliminate shared-platform dependencies.
When decommissioning a tenant or business unit, preserve required revisions and audit evidence before deleting the ADOM or removing devices. A clean exit process is part of multi-tenancy design. Without it, teams may lose the very configuration history and administrative evidence that centralized management was meant to preserve.
Capacity planning also belongs in the ADOM conversation. Large numbers of ADOMs, policy objects, revisions, and managed devices increase administrative and platform complexity. Review FortiManager sizing and supported maximums for the target release instead of assuming logical separation has no system-level cost.
When policy or ownership spans tenants, define the exception explicitly. A shared security service may need visibility across several ADOMs, but that should be granted through deliberate administrator scope and process rather than by collapsing all tenants into one domain. Cross-tenant access is a governance decision and should be auditable.