Why Firewall Configuration Is the Foundation of Compliance
If you manage Cisco Meraki networks and have been through any kind of compliance assessment, you already know: the firewall is the first thing auditors check. It does not matter whether you are working toward Cyber Essentials+, PCI-DSS, NIST CSF, or CIS Benchmarks — every standard starts with network boundary security controls, and every boundary starts with the MX appliance.
This is not arbitrary. The firewall is the single configuration surface that determines what traffic enters and leaves your network. A misconfigured MX can silently undermine every other security investment you have made. Endpoint protection, identity management, encryption — all of it sits behind a set of firewall rules that either enforce your security posture or punch holes through it.
The compliance standards all converge on the same core expectations, even if they phrase them differently. Cyber Essentials+ requires a default-deny posture on boundary firewalls. PCI-DSS requires network segmentation isolating cardholder data environments. NIST CSF's Protect function mandates access control enforcement at network boundaries. CIS Benchmarks Level 1 covers all of the above and more, with prescriptive configuration checks.
The Meraki MX is an excellent security appliance — but its out-of-the-box defaults are designed for ease of deployment, not compliance. That means you need to actively configure it to meet these standards. Here are the eight best practices that matter most.
MX Firewall Rule Types Explained
Before diving into best practices, it helps to understand the different rule types available on the MX. If you are already familiar with the Meraki appliance, skip ahead. For everyone else, here is a brief overview.
- L3 firewall rules — Traditional stateful firewall rules that filter traffic by source IP/CIDR, destination IP/CIDR, protocol, and port. These are evaluated top-down for traffic entering and leaving the network.
- L7 firewall rules — Application-layer rules that can block traffic based on application signatures, content categories, or specific hostnames. These operate above L3 and give you visibility into what applications are running on the network.
- Port forwarding rules — Rules that map external ports on the MX's public IP to internal hosts. Each active port forwarding rule is an externally exposed service.
- 1:1 NAT — Maps a public IP address directly to a single internal host. All ports on that public IP forward to the internal device unless filtered by allowed inbound connections.
- 1:Many NAT — Maps a public IP to multiple internal hosts across different ports. Similar to port forwarding but using a dedicated public IP rather than the MX's WAN address.
- Group policies — Named policy bundles that can be assigned to clients or VLANs, combining bandwidth limits, L3/L7 rules, content filtering, and scheduling into a single reusable configuration.
Each of these rule types has compliance implications. The best practices below address the most critical ones.
The Eight Best Practices
Best Practice 1: Default Deny Posture
This is the single most important firewall configuration for compliance, and it is the one most commonly missing from Meraki deployments.
By default, the Meraki MX has an implicit allow rule at the bottom of the L3 firewall rule list. This means any traffic that does not match a preceding rule is allowed through. For a fresh deployment this makes setup easy — everything works immediately. For compliance, it is a critical failure.
Every major compliance standard requires a default-deny posture. Cyber Essentials+ is explicit: boundary firewalls must deny all inbound traffic by default, with specific rules allowing only what is needed. PCI-DSS Requirement 1 demands the same. NIST and CIS both require that network devices deny traffic unless explicitly permitted.
The fix is straightforward. Add an explicit deny-all rule as the last entry in your L3 firewall rules: source Any, destination Any, protocol Any, action Deny. Then place your specific allow rules above it. This inverts the default behaviour and ensures that only explicitly authorised traffic can pass through the MX.
Without a deny-all rule at the bottom, your firewall is not a firewall. It is a router with a rule list nobody checks.
Best Practice 2: Eliminate Any-Any Rules
An allow rule with source set to Any, destination set to Any, and no port restrictions is functionally equivalent to disabling the firewall for whatever traffic matches its position in the rule list. These rules appear in Meraki deployments more often than you might expect, usually left behind from initial setup or troubleshooting sessions where someone temporarily opened everything and forgot to remove it.
Any-any allow rules fail every compliance standard. CE+ explicitly flags overly permissive rules. PCI-DSS requires that firewall rules restrict connections between untrusted networks and systems in the cardholder data environment. CIS Benchmarks require that every allow rule be documented with a business justification and scoped to specific sources, destinations, and ports.
Audit your L3 rules and replace any-any entries with specific rules that define exact source and destination CIDRs, protocols, and ports. If you cannot articulate why a rule exists and what traffic it is meant to allow, it should not be there.
Best Practice 3: Minimise Port Forwarding
Every port forwarding rule on the MX exposes an internal service to the public internet. Each one is an attack surface. Common examples include RDP (port 3389), SSH (port 22), HTTP/HTTPS for internal web applications, and security camera DVR interfaces.
PCI-DSS is particularly strict here: any service reachable from the internet that connects to the cardholder data environment must be documented, justified, and secured. But even outside PCI scope, unnecessary port forwarding rules are a compliance risk across all standards.
The best practice is to audit every port forwarding rule and 1:1 NAT mapping quarterly. For each one, ask three questions. Does this service need to be publicly accessible? Is there a documented business justification? Could it be replaced with a VPN connection instead? Meraki's client VPN or site-to-site VPN features can replace many port forwarding rules entirely, eliminating the external exposure.
Best Practice 4: Enable IDS/IPS
The Meraki MX with an Advanced Security licence includes Intrusion Detection and Prevention (IDS/IPS) powered by the Snort engine. This is a significant security capability that many organisations leave disabled or set to detection-only mode.
For compliance purposes, there are two settings that matter. First, the mode must be set to "prevention", not just "detection". Detection mode logs threats but allows them through. Prevention mode actively blocks known attack signatures. Second, the ruleset must be set to "security" (the most comprehensive option) rather than "connectivity" or "balanced", which prioritise traffic flow over protection.
NIST CSF's Detect function specifically calls for continuous monitoring and threat detection at network boundaries. CIS Benchmarks require IDS/IPS on perimeter devices. CE+ requires that boundary devices provide protection against known attack patterns. If your MX has the Advanced Security licence and IDS/IPS is not in prevention mode, you are paying for a capability you are not using — and failing compliance checks in the process.
Best Practice 5: Enable AMP (Advanced Malware Protection)
Advanced Malware Protection on the MX provides network-level file scanning. When enabled, files passing through the MX are checked against Cisco's threat intelligence database and can be blocked if they match known malware signatures.
This is a specific requirement for Cyber Essentials+. The malware protection control requires that network-level malware protection is active on boundary devices where available. If your MX has the Advanced Security licence and AMP is disabled, that is a direct CE+ failure.
Enable AMP in the Meraki Dashboard under Security & SD-WAN > Threat protection. The setting is binary — enabled or disabled. There is no partial mode. Once enabled, the MX will scan files crossing the network boundary and block known threats. This complements endpoint-level antivirus but operates at the network layer, catching threats before they reach individual devices.
Best Practice 6: Segment with VLANs and Inter-VLAN Rules
A flat network — where every device sits on the same subnet and can communicate freely with every other device — is a compliance failure waiting to happen. PCI-DSS requires that cardholder data environments be segmented from general-purpose networks. CE+ expects that different trust levels are separated. CIS and NIST both mandate network segmentation as a fundamental control.
On the Meraki MX, segmentation starts with VLANs. At minimum, most networks should separate:
- Corporate devices — workstations, laptops, printers on a trusted VLAN
- Guest WiFi — isolated VLAN with internet access only, no access to internal resources
- IoT devices — cameras, sensors, smart devices on their own VLAN with restricted access
- Point-of-sale systems — if applicable, POS terminals must be on a dedicated VLAN per PCI-DSS
- Servers / infrastructure — separated from user devices with controlled access
VLANs alone are not enough. You must also configure inter-VLAN firewall rules on the MX to control east-west traffic between these segments. Without inter-VLAN rules, devices on different VLANs can still communicate through the MX's routing layer. The goal is to ensure that guest WiFi cannot reach your servers, IoT devices cannot access corporate workstations, and POS systems are isolated from everything except what they specifically need.
Best Practice 7: Configure Content Filtering
Content filtering on the MX provides an additional layer of protection by blocking access to known malicious URL categories, phishing sites, and other high-risk web destinations. While this is primarily a user protection feature, it has compliance relevance as well.
At minimum, block the malware, phishing, and botnet URL categories. These are categories that no legitimate business traffic should ever need to reach. Beyond that, consider blocking categories like peer-to-peer file sharing and proxy/anonymiser sites, which are common vectors for data exfiltration and policy bypass.
Content filtering is configured under Security & SD-WAN > Content filtering in the Meraki Dashboard. The blocked categories apply to all traffic passing through the MX, providing a network-wide safety net that complements DNS-layer and endpoint-level protections. For compliance, having content filtering configured demonstrates defence-in-depth — a principle every standard rewards.
Best Practice 8: Review Rules Regularly
Firewall rules accumulate over time. Someone adds a port forwarding rule for a temporary project. A contractor needs access and an allow rule is created. A VLAN is added for a new office wing. Six months later, the project is finished, the contractor is gone, and the office wing has been reorganised — but the rules are still there.
Rule sprawl is one of the most common compliance findings across all standards. CIS Benchmarks require that firewall rules be reviewed at least quarterly. PCI-DSS Requirement 1.1.7 mandates review of firewall and router rule sets at least every six months. CE+ expects that rules are reviewed and that unnecessary rules are removed.
Establish a quarterly review cadence. For each rule, verify that it is still needed, that the source and destination are still correct, that the ports and protocols are still appropriate, and that there is a documented business justification. Remove anything that cannot be justified. Add comments to the rules that remain — Meraki supports a comment field on L3 rules, and using it makes future reviews significantly easier.
The Compliance Mapping
Not every best practice applies to every standard. Here is how the eight practices map to the four major compliance frameworks that MerakiGuard supports.
| Best Practice | CE+ | PCI-DSS | NIST CSF | CIS |
|---|---|---|---|---|
| 1. Default Deny Posture | Required | Required | Required | Required |
| 2. Eliminate Any-Any Rules | Required | Required | Required | Required |
| 3. Minimise Port Forwarding | — | Required | — | Required |
| 4. Enable IDS/IPS | — | — | Required | Required |
| 5. Enable AMP | Required | — | — | Required |
| 6. VLAN Segmentation | Required | Required | Required | Required |
| 7. Content Filtering | — | — | — | Required |
| 8. Regular Rule Review | — | Required | — | Required |
CIS Benchmarks are the most comprehensive, covering all eight practices. PCI-DSS and CE+ each cover five. NIST CSF covers four but with broader framing that encompasses additional controls beyond the firewall. The takeaway: if you implement all eight, you cover every standard simultaneously.
Automating Firewall Compliance Checks
You can verify all of these best practices manually by logging into the Meraki Dashboard, navigating to each configuration page, and reviewing the settings one at a time. For a single MX on a single network, that takes about 20 minutes. For an MSP managing 30 organisations with multiple networks each, it takes days — and it needs to happen quarterly at minimum.
Every setting described in this article is available through the Meraki Dashboard API. L3 firewall rules, L7 firewall rules, port forwarding rules, NAT mappings, IDS/IPS settings, AMP configuration, VLAN configuration, inter-VLAN rules, and content filtering settings are all exposed as read-only API endpoints. The data is there. What has been missing is a tool that pulls it together, maps it to compliance controls, and tells you where you stand.
That is exactly what MerakiGuard does. Connect your Meraki organisation with a read-only API key, run a scan, and get a compliance scorecard that checks every best practice in this article — across Cyber Essentials+, PCI-DSS, NIST CSF, and CIS Benchmarks. Each check returns a pass or fail result with the actual configuration values as evidence, plus remediation guidance for every failure.
No agents to install. No write access to your network. No configuration changes. Just a clear picture of where your MX firewall configuration stands against the standards that matter to your business.