Whitepaper NIS2 Readiness Check DE

Multi-vendor coverage

One platform, every vendor's syntax

A real estate is never one vendor. It is Palo Alto in the data center, Fortinet at the branch, a Check Point cluster nobody wants to touch, and three clouds that each call a rule something different. FwChange reads all of them and normalizes every rule to one vendor-agnostic model, so review, conflict analysis, and audit work the same way no matter what enforces the policy.

How the model works → See the platform

Vendor-agnostic by design

Stop translating in your head

Every vendor models a rule differently: address objects here, service groups there, security zones somewhere else. The translation usually lives in one engineer's head, which is exactly where an audit can't see it.

  • One rule model, source, destination, port, action, intent, regardless of the platform underneath.
  • Native APIs, not screen-scraping, each driver speaks the vendor's own management interface.
  • Read-first, analyse and prove before anything writes back to a device.
Palo Alto, security policy 443Normalized
Fortinet, firewall policy 443Normalized
Check Point, access rule 443Normalized
Cisco ASA, access-list 443Normalized
One rule · four syntaxes · one viewUnified

Production ready

The four platforms most European estates run on

These drivers carry the full read-analyse-write path with rule CRUD, policy queries, and config backup, and are exercised against the vendor versions below.

Palo Alto Networks

PAN-OS XML API · API-key auth · rule CRUD, policy queries, health and config backup. Tested against PA-VM 10.x and 11.x, physical, VM and cloud.

Fortinet FortiGate

FortiOS REST API · API-token auth · firewall policies, address objects, services and VPN config. Tested against FortiOS 6.x and 7.x on appliances, VM and cloud.

Check Point

R80+ Web API · API-key plus session auth · access rules, NAT, object management and policy install. Tested against R80.40 and R81.x on appliances and CloudGuard.

Cisco ASA

REST API · basic auth · access lists, object groups, NAT and VPN. Tested against ASA 9.x across ASA 5500-X, Firepower and ASAv deployments.

Supported

The rest of a mixed estate

The platforms a migration actually meets along the way: second Cisco lineages, the on-prem appliances, and the cloud and SASE control planes where rules increasingly live.

Cisco FTD / FMC

FMC REST API · token auth · access policies, object management and deploy tasks. Tested against FMC 7.x on Firepower appliances and FTDv.

Cisco Meraki MX

Dashboard REST v1 · API-key auth · cloud-managed layer-3 and layer-7 firewall rules across the MX series.

Juniper SRX

Junos REST and NETCONF · token or certificate auth · security policies and address books. Tested against Junos 21.x and 22.x.

F5 BIG-IP AFM

iControl REST · basic or token auth · AFM firewall rules and address lists. Tested against BIG-IP 15.x and 16.x.

OPNsense

REST API · API-key plus secret · rules and aliases on the open-source platform. Tested against 22.x, 23.x and 24.x; pfSense 2.6/2.7 runs through the same driver.

Cloud, AWS & Azure

AWS SDK for EC2 security groups and VPC; Azure SDK for network security groups and Azure Firewall. IAM and service-principal auth respectively.

Beyond these, the same normalization model reaches further across cloud and SASE control planes: additional providers, open-source platforms, and FWaaS edges, for a total of 33+ vendors. The four production-ready drivers above are the ones a regulated change can lean on today; the rest read and normalize so a mixed estate stays on one trail.

At a glance

API, auth and tested versions

What each driver talks to, how it authenticates, and the vendor releases it has been exercised against.

VendorAPIAuthenticationTested versionsTier
Palo Alto NetworksPAN-OS XML APIAPI keyPA-VM 10.x, 11.xProduction ready
Fortinet FortiGateFortiOS REST APIAPI tokenFortiOS 6.x, 7.xProduction ready
Check PointR80+ Web APIAPI key + sessionR80.40, R81.xProduction ready
Cisco ASAREST APIBasic authASA 9.xProduction ready
Cisco FTD / FMCFMC REST APIToken authFMC 7.xSupported
Cisco Meraki MXDashboard REST v1API keyMX seriesSupported
Juniper SRXJunos REST + NETCONFToken / certificateJunos 21.x, 22.xSupported
F5 BIG-IP AFMiControl RESTBasic / tokenBIG-IP 15.x, 16.xSupported
OPNsenseREST APIAPI key + secret22.x, 23.x, 24.xSupported
AWSAWS SDK (EC2)IAM credentialsEC2, VPC security groupsSupported
Microsoft AzureAzure SDKService principalNSG, Azure FirewallSupported
SASE / FWaaSProvider REST / GraphQLAPI key / tokenCloud-delivered edgesSupported

Coverage is the easy part. The method is the point.

Reading every vendor only matters if the change on top of it is reviewed, analysed, and provable. That logic comes from 280+ migrations across regulated European estates, written down on the methodology page.

Read the methodology See the platform →