Firewall administration often accumulates gradually. An installation engineer creates an account, a support provider receives temporary access, an internal employee changes role and an automation task gains credentials. Months later, the organisation may know who normally manages the firewall without knowing every route through which it can be administered.
A FortiGate administrator access review makes that ownership explicit. Its purpose is to establish who can change the device, what each account is intended to do, where access should originate and how the organisation will recover control when ordinary access fails.
This is a review framework rather than a configuration script. FortiOS release, authentication method and management design affect the available controls. Any changes should be checked against the documentation for the deployed version and introduced through an approved maintenance process that preserves a tested recovery route.
Begin with an account inventory that has names behind it
List the administrative accounts and associated authentication arrangements. For each entry, record a human owner or accountable service owner, business purpose, assigned permissions and expected use. An account called “support” is not sufficiently explained until the organisation knows which support team uses it and under what authority.
Distinguish personal administrative accounts, emergency accounts and service credentials. They have different review needs. A person’s access follows employment and role changes. An emergency account follows custody and testing procedures. A service credential follows the lifecycle of the system that uses it.
Investigate entries that nobody recognises. Do not delete them impulsively if an operational dependency is plausible, but do not leave them indefinitely because their history is inconvenient to establish. Assign an investigator, a decision date and a controlled way to test the impact of removal.
Record ownership outside the firewall as well. If the only explanation of an account is stored on the device being reviewed, a lockout or hardware incident can make the review record unavailable when it is most needed.
Match permissions to actual administrative work
Ask each owner which tasks the account must perform. Viewing logs, reviewing configuration and changing network policies are different responsibilities. Access should be justified by the work, not by the assumption that every technical person needs unrestricted control.
FortiOS 7.4.8 documents administrator access profiles through its system access-profile configuration reference. Use the permissions supported by your release to implement the approved division of responsibilities, and verify the resulting experience with a suitable test account before relying on it operationally.
A restricted role must still be usable for its intended task. If an engineer cannot obtain the information needed to diagnose a fault, they may repeatedly request broader access. Investigate whether the role design is incomplete or whether the task genuinely requires a different approval route.
Review powerful accounts individually. Explain why each needs its scope, who approves its use and whether routine work can occur through a narrower account. The aim is a defensible allocation of authority, not a superficial reduction in the number of account entries.
Draw the management access path
Document how an administrator reaches the device. Include the workstation or support environment, intermediate access services, network path and FortiGate interface involved. This exposes dependencies that an account list alone cannot show.
A management path should be intentional. Decide which locations and network sources are approved, which access protocols are required and which interfaces need administration enabled. Have the technical team assess the complete design, including controls outside the firewall, rather than reviewing a single setting in isolation.
The FortiOS 7.4.8 system administrator reference includes trusted-host settings for administrative source addresses or subnets. Confirm the behaviour of the selected control for the actual authentication arrangement and release. A source restriction complements account controls; it does not establish that every device on an allowed network is trustworthy.
Check both normal and alternative routes. An unused interface, temporary troubleshooting path or old remote-support arrangement can remain relevant even if administrators no longer use it regularly. Document removal decisions and verify that the intended management route still works afterward.
Understand remote authentication dependencies
Centralised authentication can connect administrative access to an organisational identity process. Fortinet’s FortiOS 7.4.8 administration documentation describes remote administrator authentication options including LDAP, RADIUS and TACACS+. The supported design and authorisation behaviour must be confirmed for the chosen method.
Map the dependencies involved in that sign-in. Name resolution, network connectivity, identity services and relevant certificates may all matter depending on the architecture. An administrator access review should explain what happens when one of those dependencies is unavailable.
Verify how permissions are assigned and changed. A group membership adjustment may have consequences beyond one device, while a local profile may remain in place after an identity-side change. The team should be able to explain the authoritative source for each part of the access decision.
Include multifactor requirements in the design review where appropriate, and confirm supported implementation for the exact environment. Do not assume that an authentication label alone proves the required factor is enforced for every administrative route.
Give third-party access a clear beginning and end
External support access needs a named sponsor inside the organisation. That sponsor should understand what the provider is authorised to do, when access is needed and how completed work is reviewed. A contract relationship does not automatically define technical permissions.
Use a specific scope for temporary work. If a provider is investigating a branch routing issue, describe the devices and activities involved. Broader access should require a reason that can be reviewed rather than becoming the default because it is easier to arrange.
Agree how changes are recorded. The organisation should receive enough information to understand the resulting configuration, the purpose of changes and any outstanding risks or follow-up actions. Avoid a support model in which only an external individual’s memory explains the current state.
At the end of the engagement, review accounts, credentials and access paths together. Removing a named account may leave a shared credential or alternative route behind. Maxicon’s IT services can provide a starting point for discussing support responsibilities and the administrative boundaries your organisation expects.
Design emergency access for a real outage
An emergency access procedure must work when the ordinary path does not. Identify the failure scenarios it is intended to address, such as an unavailable identity service or loss of remote management connectivity. Different scenarios may require different recovery arrangements.
Record who can authorise use, who can retrieve the necessary credentials and how the activity will be documented. Protect the recovery material in an approved location that remains available during the relevant outage. A password stored only behind the failed authentication service is not a dependable recovery arrangement.
Test the procedure under controlled conditions. The test should demonstrate that the authorised person can obtain access and perform the intended recovery task without exposing credentials or disrupting production unnecessarily. Record limitations, including situations that still require physical access or specialist support.
After emergency use, review the activity and update credentials or custody arrangements as required by the organisation’s process. Emergency access should remain an exceptional, accountable route rather than becoming the most convenient way to perform routine changes.
Review evidence without mistaking absence for assurance
Examine available administrative activity records using the logging capabilities and retention arrangements of the installed environment. Look for actions that do not align with the account’s stated purpose, unexpected access times or changes without a corresponding record.
Treat unusual activity as a reason to investigate, not an automatic conclusion about intent. Maintenance work, time-zone differences or an incomplete change record may explain the observation. Preserve evidence and ask the accountable owner for context through the organisation’s normal review process.
Also check whether the expected evidence exists. If administrative logging is incomplete or retained for too short a period, state that limitation. “No unexplained activity found” means less when the review covers only a small fraction of the relevant time.
Assign actions from the review. An unclear account, excessive permission or undocumented support path should have an owner and a due date. Without this follow-through, the review becomes an inventory exercise that leaves the underlying access decisions unchanged.
Make access changes without locking out the team
Plan changes in a sequence that preserves control. Verify a working approved administrative route before removing an old one, and keep the recovery procedure available. The precise implementation should be checked by an engineer familiar with the deployed release and topology.
Test the intended restriction as well as continued access. An authorised administrator should be able to complete the approved task, while an unauthorised source or role should encounter the expected boundary. Use controlled tests and record their scope rather than experimenting from arbitrary networks.
Separate unrelated changes where practical. Revising permissions, altering authentication and closing a management interface simultaneously can make a failure difficult to diagnose. A staged sequence gives the team clearer evidence about which adjustment produced which result.
Update the ownership record after successful verification. Include any residual exceptions, the next review date and the conditions that should trigger an earlier review, such as a provider change, staff departure or management-network redesign.
Keep the review proportionate and repeatable
A small office may need a concise account register and a short recovery exercise. A larger estate may need a formal review across several administrators and identity systems. The essential questions remain the same: who has authority, why they have it, how they reach the device and how that authority ends.
Integrate those questions into onboarding, offboarding and change management. This reduces the amount of detective work required during the next periodic review. Access ownership stays more accurate when ordinary business events update it.
If your team needs to clarify firewall administration responsibilities, contact Maxicon with the current support arrangement and management approach. The useful outcome is an access model that the organisation can explain, operate and recover throughout the device’s service life.
Frequently asked questions
Is one shared administrator account sufficient for a small team?
A shared account makes individual responsibility harder to establish. Prefer an arrangement that identifies who performed administrative work, subject to the supported platform design. Keep emergency or service accounts distinct and document their owners, purpose and custody rules.
Do trusted hosts replace strong authentication?
No. Source restrictions and authentication address different parts of the access decision. Confirm both within the complete management design, including the systems on the approved network and any alternative administrative paths.
Should unused accounts be deleted immediately?
Investigate their ownership and dependencies first, then remove or disable them through a controlled process. Unknown accounts should have a prompt decision route, but an unplanned deletion can interrupt automation or support if their purpose has not been established.
How often should administrator access be reviewed?
Choose a periodic interval appropriate to your operational risk and review again when people, providers or authentication arrangements change. Event-driven reviews help prevent obsolete permissions from remaining until the next scheduled exercise.
What proves that emergency access is usable?
A controlled rehearsal demonstrating that authorised staff can retrieve the required material and complete the intended recovery task. Record the tested scenario and its limits. The existence of a sealed password or written procedure alone does not prove recoverability.
Related technology support
For an additional service perspective related to this guide, explore Trubyte’s Fortinet and managed security services.
Discuss your requirements with Maxicon
Tell us about your business, current environment and the support you need.
