Resources

Understand the product before you buy it

The deliverable, the export guide, the method and the control library, all readable without an account

Sample report

A complete deliverable on a fictional configuration, including the scope and limitations section that states what could not be proven. This is the document a client receives.

Open the sample report

Supported export guide

What to upload, and how to produce it

Supported today

Palo Alto Networks PAN-OS, a standalone firewall: the configuration XML.
A Panorama-managed firewall: the device state export (.tgz), from which ConfigProof builds the effective configuration (local configuration plus what Panorama pushed), or the merged configuration from the CLI or the XML API.
Panorama, an XML export analyzed as a management model: device groups, shared, pre-rulebase and post-rulebase policy, templates, template stacks and variables.
A bounded Panorama bundle: a ZIP holding the Panorama export plus one or more managed-firewall XML exports, matched with your confirmation before any asset is created.
Fortinet FortiGate: the configuration backup (.conf), including a multi-VDOM backup, one analysis per VDOM.
Cisco Secure Firewall Threat Defense: an FMC or cdFMC read by the ConfigProof Collector (the manager and every FTD it manages), an FDM read, or show running-config from the device.
Cisco ASA: show running-config, or show running-config all-contexts from a multiple-context ASA, one analysis per context.
Check Point: a Security Management Server, Multi-Domain Server or Smart-1 Cloud read by the ConfigProof Collector (the manager and its gateways), or a gateway read over Gaia.

How to produce the export in the web interface

01Standalone firewall: Device > Setup > Operations > Export named configuration snapshot, and choose running-config.xml.
02Panorama-managed firewall: Device > Setup > Operations > Export device state. The .tgz holds the running configuration and what Panorama pushed. Upload it as it is.
03Panorama: Panorama > Setup > Operations > Export named Panorama configuration snapshot, and choose running-config.xml.
04Do not rename a file to disguise the vendor: ConfigProof detects vendor, version and export type from the content, not the file name.

Before you upload

On a Panorama-managed firewall, Export named configuration snapshot gives only the firewall's local configuration: no device group rules and objects and no template settings. ConfigProof accepts it, but the device state or merged export is the complete one.
A configuration export contains no logs, hit counts, sessions or routing table state, so nothing in the report will claim them.
A Panorama-only export is a management-model analysis. It is not the effective configuration of every managed firewall.
The raw file is deleted as soon as it is normalized. Keep your own copy if you need one.

Why an upload is refused

The file is larger than 120 MB, which is the ceiling this deployment accepts.
The file is not a configuration export: a tech support file or a saved error page from the browser. Export the configuration itself.
The file was cut short by a download or copy, so the XML does not close. Export it again and check the size matches.
A device state archive that expands beyond what an export holds.
A device state archive that holds no running configuration, or more than one.
The file is from a vendor ConfigProof does not read today.

From the CLI or the XML API

Firewall CLI, merged configuration (local plus what Panorama pushed). Save the output to a .txt or .xml file and upload it.
```
set cli pager off
set cli config-output-format xml
show config merged
```
Firewall or Panorama CLI, running configuration (on a managed firewall, local only)
```
set cli pager off
set cli config-output-format xml
show config running
```

Firewall XML API, merged configuration (the answer is wrapped in <response><result>, which ConfigProof accepts)

read -rs PANOS_API_KEY
curl --cacert firewall-ca.pem -H "X-PAN-KEY: $PANOS_API_KEY" -G \
  --data-urlencode 'type=op' \
  --data-urlencode 'cmd=<show><config><merged></merged></config></show>' \
  -o merged-config.xml "https://<firewall>/api/"

Firewall XML API, device state archive

read -rs PANOS_API_KEY
curl --cacert firewall-ca.pem -H "X-PAN-KEY: $PANOS_API_KEY" \
  -o device-state.tgz "https://<firewall>/api/?type=export&category=device-state"

Firewall or Panorama XML API, the configuration file (on a managed firewall, local only)

read -rs PANOS_API_KEY
curl --cacert device-ca.pem -H "X-PAN-KEY: $PANOS_API_KEY" \
  -o running-config.xml "https://<device>/api/?type=export&category=configuration"

Firewall or Panorama CLI, copy a file off the device

scp export device-state to user@backup-host:/exports/
scp export configuration from running-config.xml to user@backup-host:/exports/

The API key is read without echo and sent as a header, so it stays out of shell history and URLs. Keep TLS verification on: point curl at the device's CA certificate instead of disabling it. A read-only admin role with XML API access is enough. CLI output may keep the prompt lines around the configuration: ConfigProof removes plain text before and after the document and refuses anything else around it.

What a configuration export cannot carry

Serial number, hardware model, and the installed content, application, threat and GlobalProtect client versions. These are device state, not configuration.
Session tables, hit counts, logs and the live state of tunnels and routes.
To see those, the device has to be read directly over SSH or the API. Until ConfigProof reads a device that way, the report states these as not present rather than guessing them.

What each export contains

Named configuration snapshot (firewall): The firewall's local configuration. On a Panorama-managed firewall it does not include the device group rules and objects or the template network and device settings Panorama pushed.
Device state (firewall, .tgz): The running configuration and, on a Panorama-managed firewall, the pushed shared policy and template stack. ConfigProof keeps only those documents and discards the rest of the archive (copies, history, certificate information and other device state) before storing anything.
show config merged (firewall): The effective configuration: local configuration combined with what Panorama pushed. Text output, no device state.
show config running (firewall): The local configuration only, like the named snapshot.
Named Panorama configuration snapshot: Panorama's own configuration: device groups, templates, template stacks and shared policy. It does not include any firewall's local configuration.

How to build a Panorama bundle

01Export the Panorama configuration (Export named Panorama configuration snapshot) and each managed firewall's configuration XML.
02Put the XML files in one ZIP. A device state archive cannot go inside a bundle: upload it on its own.
03In New analysis, choose the Panorama bundle and upload the ZIP. Each firewall is matched to its Panorama by serial, and you confirm every match before anything is created or charged.

The collector script

Nothing to install. One readable PowerShell file runs on a jumpbox that already reaches the firewall or Panorama, asks for the address and the credentials, exports the device state, and either uploads the result with a one-time token or writes it to disk for you to upload by hand.

Two ways to run it

With a one-time token: Create a collector token under Settings, Collector. Run the script with -Upload and it asks for the token, checks whose workspace it belongs to, and prints that name in the plan you confirm before the device is touched. The token is never a command-line argument, and the environment variable is read only under -Force, because two tokens look identical and one left over from another engagement would otherwise deliver into the wrong workspace. It is single use by default, expires within a week at the outside, and can be revoked at any time.
Offline, to a file: Run the script with -OutputDirectory and no -Upload. It creates a new folder inside the one you named, restricts it to your account and the machine's administrators, writes the device state and the show system info output into it, and tells you which file to upload through New analysis. On a filesystem with no permissions to set, a mapped share or a container volume, it says so rather than pretending. Nothing leaves the jumpbox. Use this when the jumpbox has no route to the internet, and delete the folder once it is uploaded: a device state export contains private keys, pre-shared keys, bind credentials and password hashes.

What it does, in order

01Asks for the collector token, checks with ConfigProof whose workspace it belongs to, and prints the workspace name, the address, and the exact API calls it is about to make. Then it waits for you to confirm.
02Asks for the administrator name and password. The password is read as a secure string, is never written to disk, never appears in the command line, and is never logged.
03Generates an API key with type=keygen.
04Exports the device state with type=export&category=device-state, or the configuration when the target is a Panorama.
05Runs show system info with type=op, keeps six fields out of it, and drops the rest. Those six are where the serial, the model and the hotfix in the version come from; an export carries none of the three.
06Uploads with the token, or writes both files into a new folder restricted to your account, tells you what is in it and what to upload, and says so if the permissions could not be set.

The read-only account to create first

Use a dedicated administrator with an Admin Role that can read and nothing else. Do not use a superuser, and never let the script try a list of passwords: that locks accounts and wakes the customer's SOC. A dedicated account matters for a second reason: the API key the script generates is not a session. PAN-OS derives it from the account's password and the device master key, so the same call returns the same key every time, it outlives the run, and there is no way to revoke that one key. What invalidates it is changing the account's password, rotating the master key, or disabling or deleting the account.

01Device, Admin Roles, add a role. Set the role type to Dynamic and choose Superreader, or build a custom role and turn every write privilege off.
02In the custom role, leave XML API, Configuration enabled. Without it the export comes back empty.
03Leave XML API, Operational Requests enabled. That is what show system info uses.
04Device, Administrators, add an administrator with that role. No CLI access, no commit rights.
05On Panorama, the equivalent is the Panorama superreader role. One account there covers every managed firewall through target=<serial>.
06If change control requires it, create the account, run the collection, and disable the account again.
07Because the API key is derived and not issued, plan how you will invalidate it: change the account's password after the engagement, or disable the account. There is no revoke button for a single key.

What leaves the jumpbox

The device state export, and six fields out of show system info: hostname, serial, model, software version, family and management address. The rest of that output, which includes the netmask, the MAC, the uptime and the content versions, is dropped on the jumpbox before anything is sent.
The destination is the ConfigProof address the token belongs to. Pointing it anywhere else needs both -ApiBaseUrl and an explicit acknowledgment, which -Force does not waive, and no redirect is ever followed.
No credential is uploaded, written to disk, put on a command line or logged. The administrator password and the collector token live in memory for the length of the run. The API key does too, but it is derived from the account rather than issued, so it stays valid on the device until that account's password changes.
The upload creates no firewall record and consumes no Assessment Cycle. It waits under New analysis until an engineer confirms what it is.

Getting the script

It ships in the ConfigProof repository at collector/configproof-collect.ps1. One file, no modules, no installer. Read it before you run it; it is written to be read, and your platform team will want to before they allow it on a jumpbox.

Where it will not run, and what to do

Management Profile, Permitted IP: An interface management profile with an empty Permitted IP list denies everything, whatever the security policy says. The symptom is a firewall that answers ping and drops the API connection with no log entry you would notice. Add the jumpbox address to the permitted list on the management interface, or add 0.0.0.0/0 if that is your existing posture.
AppLocker and WDAC: A jumpbox under application control may refuse to run an unsigned script. Ask the platform team to allow the file by hash, or run it through a signed PowerShell host, or use the offline mode from a workstation that is allowed to run it and upload the file by hand.
Constrained Language Mode: In Constrained Language Mode the script cannot construct the .NET objects it needs for the TLS and the HTTP call. Check with $ExecutionContext.SessionState.LanguageMode. If it says ConstrainedLanguage, run the collection from another machine and upload the file by hand.
PowerShell 5.1 and TLS: Windows PowerShell 5.1 does not always negotiate TLS 1.2 by default. The script sets it for its own session and does nothing to the machine.
A self-signed management certificate: Certificates are verified by default. Pass -AllowSelfSignedCertificate to accept a self-signed management certificate; the script prints a warning and says so in its summary. It is never silent and there is no way to turn verification off without saying so on the screen.
A scheduled task: Pass -Force to skip the confirmation. Nothing is then asked for at a prompt, so every credential comes from the environment: CONFIGPROOF_PANOS_USER, CONFIGPROOF_PANOS_PASSWORD and CONFIGPROOF_COLLECTOR_TOKEN, injected from your existing secret store. Do not put any of them in the task definition; the script has no parameter for them precisely so that cannot happen.
Behind more than one proxy: The upload endpoint counts requests per caller network, and it reads that from X-Forwarded-For counting back from the right. A self-hosted deployment sets TRUSTED_PROXY_HOPS to the number of proxies in front of it, one for the standard compose file. A deployment that gets it wrong either lets a caller choose their own budget, if it is too high, or gives everybody behind the last proxy one shared budget, if it is too low. A request whose network cannot be read at all is refused, because an endpoint that cannot tell its callers apart cannot bound any of them.

Analysis methodology

How a finding gets made, and what decides its severity

The pipeline

01Hardened parse of the export, with entity resolution and network access disabled.
02Vendor and version detection from content, never from the file name.
03Normalization into immutable entities plus a reference graph over every configuration relationship.
04Deterministic controls over the selected modules only.
05Evidence capture: control ID, configuration path, normalized values, affected entity IDs.
06Optional model enrichment of the wording, validated against a strict schema.
07Scoped Assessment Score and Configuration Coverage, always reported together.

Score and coverage, never one without the other

A score computed over four modules is not the same claim as a score computed over eighteen. ConfigProof shows the Scoped Assessment Score beside Configuration Coverage everywhere it appears, in the dashboard and in the report, and a scoped assessment carries a mandatory scope and limitations section.

Configuration Coverage The share of detected modules that received full control analysis. Modules you did not select stay visible as Not analyzed rather than disappearing.

Severity and confidence are separate axes

A finding can be severe and uncertain at the same time. Base severity comes from the control definition, confidence comes from the evidence available, and the two are never blended into one number that hides both. When you override a severity, the original machine value stays on the record with your reason beside it.

Language rules

The words are chosen so a reader cannot infer a claim the analysis did not make

Configured Permitted Flow: What the configuration permits. Not a statement that traffic flows.
Configured Route: A route present in the configuration. Not a learned or installed route.
No configuration references found: Said of an object. It is not the same as saying the object is unused in production.
Candidate for runtime validation: Said of a rule that looks unused. Without hit counts, no export can prove it.
Review candidate: Said of a merge or consolidation. Safe to merge is only used when every behavior-affecting field is proven equivalent.

Control library

Every control has a stable ID, a documented predicate, a positive and a negative fixture, and a supported-version note. This is the catalog the analyzer runs, in full

Vendor PAN-OS, Panorama, Prisma Access, FortiGate, Cisco FTD, Cisco ASA and Check PointAnalyzer panos-analysis-1.32.0532 controls

Browse all 532 controls

Where a control aligns with a recommendation of the CIS Palo Alto Firewall 11 Benchmark v1.2.0, that recommendation is cited as a reference. Only that version was checked. A reference is not a certification.

Data handling guide

The raw XML lifecycle, retention by plan, what is redacted before anything is logged, what support can see and how to report a vulnerability, all on one page.

Read the security page

Changelog

Product and analyzer changes that affect a result you already published

Sep 4, 2026
Control specification adopted
Assessment Cycles, module scope selection with acknowledgment, the Scoped Assessment Score beside Configuration Coverage, the report builder with immutable revisions, the WBS Planner and the Diagram Canvas.
Aug 20, 2026
Evidence levels on every finding
Findings now carry fact, derived, contextual or hypothesis alongside confidence, and human overrides are stored beside the original machine result rather than replacing it.
Aug 2, 2026
Raw configuration deletion receipt
The deletion timestamp for the uploaded file is recorded and shown on the assessment.

An analyzer version change never rewrites a published report revision. The revision records the analyzer version that produced it.

Still deciding?

Read the security page for the data handling detail, or start with the free preview and judge the output yourself.

Get started Read the security page