Managing FortiGate admin credentials through CyberArk PSM

If you run FortiGates, there is a decent chance the admin password is known to everyone who has ever worked on the firewall, stored in a spreadsheet called something like network-passwords.xlsx, and unchanged since the last engineer who “owned the firewalls” resigned. Firewall administrator accounts are the classic unmanaged privileged account: too critical to rotate casually, too shared to attribute, and too operationally scary to touch — which is exactly the combination that makes them the account an attacker (or an auditor) goes looking for first. This guide walks through putting FortiGate admin credentials under CyberArk management: vaulted, rotated by CPM, and accessed through recorded PSM sessions.

It’s a bridge chapter: if you’ve arrived from our FortiGate content, this is what the CyberArk side of the house does with your firewall creds; if you’ve arrived from the CyberArk series, this is the pattern for network devices generally. The architectural background is in the CorePAS implementation guide.

Why firewall admin accounts stay unmanaged

Three reasons, all rational and all wrong. First, fear of lockout: a bad rotation on a domain account is an inconvenience; a bad rotation on the perimeter firewall feels existential. Second, shared operational identity: network teams often work as a unit through one account, so per-person attribution was never built. Third, the device sits outside the identity stack — no AD join, so it never got swept up in identity governance. The result in ISM terms is a shared, unrotated, largely unaudited privileged account controlling a security enforcement point. CyberArk addresses all three: reconcile-capable rotation removes the lockout fear, PSM restores attribution over a shared account, and the vault becomes the identity stack the device never joined.

What FortiGate gives you to work with

FortiOS exposes local administrator accounts (config system admin) with granular admin profiles (config system accprofile), trusted-host restrictions per account, SSH and HTTPS management access, and a REST API. That’s everything a PAM integration needs: a rotation path over SSH (or API — capabilities and endpoints vary by FortiOS version, so verify against your firmware’s documentation), and interactive access over SSH and the web GUI that PSM can broker. Note that behaviour differs meaningfully across FortiOS major versions — 6.x, 7.0, 7.2+ — particularly around API authentication and password policy enforcement, so treat version checks as step zero.

Step 1 — prepare the FortiGate

First record what you’re integrating with — get system status gives you the FortiOS version that determines your platform and plugin choices. Then create the accounts CyberArk will use, separate from the accounts humans will check out. At minimum: a rotation/reconcile account for CPM with full admin rights, locked to the CPM server’s address. On the FortiGate CLI:

config system admin
    edit "svc-cpm-reconcile"
        set accprofile "super_admin"
        set trusthost1 10.50.10.25 255.255.255.255
        set password <strong-initial-password>
    next
end

Decisions to make deliberately here:

• Trusted hosts on every managed account — the CPM account locked to the CPM host, human-checkout accounts locked to the PSM servers. This means even a leaked password is unusable from anywhere else, and it enforces “access only via PSM” at the device itself.
• Per-function accounts, not one god account: separate read-only accounts (a restricted accprofile) for monitoring tools, the CPM service account, and the vaulted admin accounts humans check out.
• VDOM scope, if you run VDOMs — decide whether managed accounts are global or per-VDOM, and mirror that structure in your safes.

Step 2 — choose and configure the platform in CyberArk

In the PVWA, you’ll need a platform for FortiGate devices. CyberArk ships and hosts (via the CyberArk Marketplace) connector and CPM plugin packages for Fortinet devices; which package matches your FortiOS version changes over time, so pull the current one from the Marketplace rather than trusting any blog post — including this one — to name it. The shape of the configuration is stable though:

• Import the platform package, duplicate it, and rename the copy for your estate (e.g. “FortiGate — Production Perimeter”) so upgrades to the shipped platform never silently change your settings.
• Set the rotation transport — SSH-based rotation is the widely used, predictable option; API-based rotation exists but is more version-sensitive. Either way CPM logs on as the reconcile account and sets the target account’s password with config system admin.
• Configure verify/change/reconcile: verification on a schedule, change on check-in or interval, reconcile as the recovery path when a password drifts (this is what removes the lockout fear — a failed change is self-healing, not a site visit).
• Match the platform’s password policy to the FortiOS password-policy settings on the device, or rotations will fail on complexity/length mismatches.

Step 3 — onboard the accounts

Safe design first, then accounts. A workable pattern for a firewall estate: one safe per environment or security zone (e.g. NET-FW-PROD, NET-FW-DR), network team as requestors, approvals required for perimeter devices, and the CPM/PSM service users as safe members. Then onboard each FortiGate’s accounts — address, SSH port, username, the platform you built, and the reconcile account linked at platform or account level. Rotate immediately on onboarding: the first rotation is the moment the spreadsheet password dies, and it’s also your end-to-end test of the platform configuration. Do the first device in a change window, watch the CPM logs, and confirm you can still log in via a checked-out credential before rolling across the fleet. Onboard the DR or lab firewall first — the blast radius of a platform misconfiguration should never be the production perimeter.

Step 4 — put PSM in front of firewall changes

Rotation fixes the credential; PSM fixes the accountability. Configure the platform’s connection components so that “Connect” from PVWA brokers the session through PSM — SSH for CLI work (via PSM for SSH or the PSM-SSH connection component), and the web GUI through a PSM web connector where your version supports it. What this buys a regulated environment:

• Attribution over a shared account: the vault knows which human checked out the session even though the FortiGate sees one admin account.
• Session recording as change evidence: the video/keystroke record of the change window pairs with the change ticket — genuinely useful at audit, not just forensics theatre.
• Credential never touches the engineer: combined with trusted-hosts pinning to the PSM servers, there is no path to the firewall that bypasses the recording.

Break-glass: design it before you need it

Once every path to the firewall runs through CyberArk, a CyberArk outage is a firewall-management outage — see the failure-drill chapter for how that day goes. Break-glass for network devices means: a dedicated local emergency account on each FortiGate, its password vaulted but also held in a sealed offline form (printed envelope in a safe, or equivalent) under dual control, with console access as the transport of last resort. Test the envelope as part of DR exercises, and treat any break-glass use as an incident: password rotated and re-sealed afterwards, use logged and reviewed. One caution: don’t design your break-glass around FortiGate’s hardware maintainer login — its availability is version- and configuration-dependent (it can be disabled, and many hardened builds do disable it), and it requires physical access and a reboot. It’s a recovery mechanism, not an operational break-glass.

The ISM and Essential Eight view

For Australian government and regulated-PII environments, this pattern maps cleanly onto the controls you’re being assessed against. Restricting administrative privileges — an Essential Eight strategy — expects privileged accounts to be individually attributable, used only for administration, and access-controlled; vaulted accounts with PSM brokering is the operational implementation of that for devices that can’t join your identity stack. The ISM’s privileged access controls similarly want privileged access logged, credentials managed and rotated, and emergency access processes defined. At higher Essential Eight maturity levels the expectations tighten towards just-in-time access and comprehensive logging of privileged sessions — which is exactly what check-out/check-in with session recording gives you. If you operate across multiple networks or security domains, the safe-and-platform design gets more interesting; the multi-domain CorePAS guide covers those gotchas.

---

Where this leaves you

Your firewall credentials now rotate, your firewall changes now have names and recordings attached, and your next problem is scale: the same pattern applied across switches, WLCs, out-of-band consoles and everything else with a local admin account — plus the question of what protects the vault that now holds all of it. For the vault-side architecture, start with the CorePAS implementation guide and its multi-domain companion; for what happens underneath the vault, the HSM chapters at The Luna Field Guide are where this series continues.