// FortiGate API · Read-Only · Live Analysis · Calgary, Canada
SHADOWATLAS FINDS THEM.
ShadowAtlas connects to your FortiGate via REST API, verifies the token is strictly read-only before touching anything, then pulls your live policy stack and surfaces every rule that is shadowed, redundant, or contradicted by something above it.
No config exports. No file uploads. No agent installation. No write access — ever. The tool refuses to run if the API token has permissions beyond read. Read-only is not a preference. It's an enforced precondition.
A shadow rule is a firewall policy that is never matched because a broader rule above it catches the traffic first. It sits in your live config, looks legitimate in the GUI, and does nothing — except give your auditors false confidence.
More dangerous: the shadow rule might be the one your team thinks is blocking lateral movement. The rule above it is not. You've been open for two years and the dashboard looked clean.
FortiGate evaluates rules top-down, first-match. Order is policy. Shadow rules are invisible risk.
Create a read-only API token on your FortiGate. Give ShadowAtlas the endpoint and the token. That's it. The tool does the rest — live, against your actual running policy.
Create a FortiGate REST API administrator with read-only profile. ShadowAtlas audits the token's effective permissions on first connect. If the token has write access to any object — the tool stops and tells you. No analysis runs until the access model is verified.
ShadowAtlas queries the FortiGate REST API directly: firewall policies, address objects, service groups, interface zones, VDOMs, NAT rules. Everything needed to model the full policy stack as it exists right now — not as it existed when someone last exported a config.
Each rule is checked against all rules above it in evaluation order. Full and partial shadowing relationships are identified across every VDOM. Redundant allows, unreachable denies, overlapping service groups — all flagged with the specific rule responsible.
ShadowAtlas pulls 30 days of traffic logs via the FortiGate API. Each policy is cross-referenced against observed traffic: what ports actually appeared, what sources, what destinations, what volume. If a policy permits ANY service but 30 days of logs show only TCP/80 — that gap is flagged with a severity score and queued for remediation.
Your live policy stack rendered as an interactive graph. Shadow relationships shown as edges. Click any rule to see what it shadows, what shadows it, and what traffic it actually matched over the log window.
NIST-aligned findings with staged remediation — log → observe → restrict. Where log analysis shows a policy wider than observed traffic, ShadowAtlas generates the tightened policy as ready-to-apply FortiGate CLI or API code. Not a recommendation to narrow it. The actual replacement config, scoped to what was seen. Review, test in log mode, apply.
Fortinet environments accumulate policy debt the same way every time. Migration rule added "just for now." Vendor exception never cleaned up. Temporary allow from three years ago that everyone forgot about. Nobody wants to touch the firewall because nobody knows what's safe to remove.
So the policy grows. The shadow rules multiply. The audit says "compliant." The logs say nothing because the deny rule above your critical block is eating all the traffic first.
The manual process — rule-by-rule comparison against a live GUI, spreadsheet cross-reference, hoping you caught everything — doesn't scale, doesn't get audited, and misses the subtle overlaps every time. ShadowAtlas does it live, via API, in minutes.
Read-only API token. Endpoint. That's the entire setup. ShadowAtlas verifies permissions, pulls the live policy, runs the analysis, and returns the shadow map and hardening report. If there's nothing to find — it says so. That hasn't happened yet.
Read-only access. Zero writes. Zero config exports. Your firewall, analyzed live, the way it actually runs.