PCI-DSS v4.0 Compliance Guide for Meraki Networks

What Changed in PCI-DSS v4.0

PCI-DSS v4.0 replaced version 3.2.1 on 31 March 2024, with the final batch of future-dated requirements becoming mandatory on 31 March 2025. If you process, store, or transmit cardholder data — or your network connects to systems that do — you are now assessed against v4.0. There is no grace period left.

The structural changes in v4.0 are significant. This is not a minor revision with a few tweaked controls. The PCI Security Standards Council redesigned the framework around five themes that directly affect how network infrastructure is assessed.

The Customised Approach

Version 3.2.1 offered a single validation method: follow the defined requirement exactly as written. Version 4.0 introduces a customised approach as an alternative. Instead of meeting a prescriptive control, you can demonstrate that your implementation meets the same security objective through a different method. This sounds flexible, but it carries a heavier burden of proof. You need a targeted risk analysis, a controls matrix, and your assessor needs to independently validate your approach. For most Meraki environments, the defined approach will remain simpler.

Targeted Risk Analysis

Several requirements now mandate a formal, documented risk analysis rather than accepting a fixed configuration value. For example, instead of prescribing a specific password length, v4.0 requires you to perform a risk analysis that justifies your authentication policy. This means your Meraki admin access configuration is no longer just a checkbox — you need to demonstrate that the settings you chose are proportionate to the risk.

Enhanced Authentication Requirements

Multi-factor authentication is no longer limited to remote access. PCI-DSS v4.0 requires MFA for all access to the cardholder data environment, including administrative access from within the network. For Meraki administrators, this means dashboard MFA enforcement is now a hard requirement, not a best practice. The standard also requires that MFA systems are resistant to replay attacks and cannot be bypassed.

Broader Encryption Requirements

The encryption requirements in v4.0 extend beyond data in transit over public networks. Encryption of cardholder data on trusted internal networks is now explicitly addressed. This has direct implications for Meraki wireless networks: WPA2-Personal on an SSID that carries cardholder data is no longer sufficient if an attacker on the same network could intercept traffic. WPA3 or WPA2-Enterprise with per-user keying becomes the expectation.

Continuous Compliance Emphasis

Perhaps the most consequential change: v4.0 makes clear that compliance is not a point-in-time event. The standard now explicitly requires that security controls are continuously monitored and that their failure is detected and responded to promptly. Annual self-assessment questionnaires are no longer enough. Your network configuration at 2am on a Tuesday in October needs to be compliant, not just the configuration your assessor reviewed in January.

PCI-DSS Requirements That Touch Your Meraki Network

PCI-DSS v4.0 has 12 top-level requirements organised into six goals. Not all of them apply to network infrastructure. The ones that do are specific and auditable. Here is the mapping to Meraki configurations.

Requirement 1: Install and Maintain Network Security Controls

This is the most directly relevant requirement. In v4.0, "firewalls" has been replaced with the broader term "network security controls" (NSCs), reflecting that modern network security includes more than traditional stateful firewalls.

On a Meraki MX, this means your L3 firewall rules, L7 firewall rules, site-to-site VPN configuration, and NAT rules are all in scope. The standard requires that NSCs restrict traffic between trusted and untrusted networks, that a default-deny posture is in place for inbound traffic, and that rules are reviewed at least every six months.

Key checks include verifying that the final L3 rule is an explicit deny-all, that no overly permissive rules exist (allow any-any), that port forwarding is minimised and documented, and that VPN tunnels only permit necessary traffic. Every rule needs a documented business justification — v4.0 requirement 1.2.5 mandates this explicitly.

Requirement 2: Apply Secure Configurations to All System Components

Default credentials, unnecessary services, and insecure configurations are the focus here. For Meraki, the cloud-managed model eliminates some traditional risks (no local admin passwords on devices), but introduces others.

Your SSID configuration is the primary audit target. SSIDs named "Unconfigured SSID" that are still enabled, SSIDs broadcasting without encryption, and wireless networks that lack client isolation are all failures. Switch port configuration matters too: ports connected to nothing should be disabled, and trunk ports should have a restricted VLAN list rather than allowing all VLANs.

The v4.0 addition here is requirement 2.2.7, which mandates that all non-console administrative access is encrypted using strong cryptography. Meraki Dashboard access is HTTPS by default, which satisfies this, but any local management interfaces or API access must also be verified.

Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know

This requirement governs who can access what. In a Meraki context, it maps to dashboard administrator accounts and their privilege levels. Not every admin should be a full organisation administrator. v4.0 requires that access is granted based on job classification and function, reviewed at least every six months, and revoked immediately when no longer needed.

The Meraki Dashboard supports organisation-level admins with full, read-only, or none access per network. Your audit needs to verify that the principle of least privilege is applied: network-specific admins should have access only to their networks, and the number of full org admins should be minimal and documented.

Requirement 8: Identify Users and Authenticate Access to System Components

This is where v4.0 raises the bar significantly. Multi-factor authentication is now required for all access into the cardholder data environment (requirement 8.4.2), not just remote access. For Meraki, this means:

• Dashboard MFA must be enforced organisation-wide. The Meraki org-level setting enforceTwoFactorAuth must be enabled. Individual admin accounts with MFA disabled are a direct PCI failure.
• Shared accounts are prohibited. Every admin must have a unique, individually assigned account. Generic credentials like "admin@company.com" fail requirement 8.2.2.
• Inactive accounts must be removed within 90 days. Requirement 8.2.6 mandates that accounts not used within 90 days are disabled or removed. The Meraki admin list needs to be audited against last-active timestamps.
• Password/passphrase complexity must meet minimum standards: at least 12 characters (or 8 if the system does not support 12), with numeric and alphabetic characters. This applies to any locally authenticated systems within the CDE.

Requirement 11: Test Security of Systems and Networks Regularly

Requirement 11 mandates regular security testing including vulnerability scanning, penetration testing, and intrusion detection. On the Meraki MX, this maps to IDS/IPS configuration and network-level security features.

Specifically, requirement 11.5 requires that network intrusions and unexpected file changes are detected and responded to. The Meraki MX IDS/IPS feature must be enabled in at least detection mode (prevention mode is preferred). Advanced Malware Protection (AMP) should be active. Content filtering, while not explicitly required by PCI, strengthens your security posture and demonstrates defence in depth.

The v4.0 future-dated requirement 11.6.1 also introduces change-and-tamper-detection mechanisms on payment pages. While this is more relevant to web application security than network infrastructure, your Meraki network segmentation determines whether a compromised segment can reach payment page servers.

The Meraki API Endpoints That Matter

Every PCI-relevant Meraki configuration can be retrieved programmatically through the Dashboard API. Here is the mapping between PCI-DSS v4.0 requirements and the specific API endpoints that provide the evidence.

All of these endpoints require only read-only API access. A compliance audit never needs to modify your network configuration. A single Meraki API key scoped to the organisation is sufficient to retrieve every data point in the table above.

Network Segmentation: The Most Common Failure

In our experience, network segmentation is the single most common PCI-DSS failure in Meraki environments. The issue is not that Meraki lacks the capability — the MX appliance supports VLANs, inter-VLAN firewall rules, and group policies. The issue is that many networks were deployed flat and never segmented after the fact.

Here is the scenario we see repeatedly: a retail or hospitality business has a Meraki MX, a few switches, and several access points. The point-of-sale system, guest WiFi, back-office workstations, and CCTV cameras are all on the same subnet. There are no VLANs. There are no inter-VLAN firewall rules. Every device can talk to every other device.

Under PCI-DSS v4.0, this means the entire network is in scope. Every device on that flat network is part of the cardholder data environment because nothing prevents any of them from reaching the POS system. Your scope explodes. Every workstation, every camera, every guest phone connected to the WiFi needs to be assessed.

Proper segmentation reduces scope dramatically:

• POS/payment VLAN — isolated subnet for point-of-sale terminals and payment processing. Firewall rules restrict this VLAN to communicate only with the payment processor and necessary management systems.
• Corporate VLAN — back-office workstations with internet access but no route to the payment VLAN.
• Guest WiFi VLAN — completely isolated. No access to any internal VLAN. Client isolation enabled at the SSID level so guests cannot see each other.
• IoT/CCTV VLAN — cameras and sensors on their own segment with no internet access and no route to payment systems.

On a Meraki MX, this is configured through the Addressing & VLANs page and enforced through L3 firewall rules. The API endpoints GET /networks/{id}/appliance/vlans and GET /networks/{id}/appliance/firewall/l3FirewallRules provide the evidence. An automated audit checks that VLANs exist, that inter-VLAN deny rules are in place, and that the payment VLAN is not reachable from guest or general-purpose segments.

The guest WiFi problem deserves special attention. If your guest SSID is on the same VLAN as any system that touches cardholder data, you have a PCI failure. It does not matter that the SSID uses a different password. VLAN-level isolation is the requirement. Check the vlanId field in the SSID configuration — if it matches the POS VLAN, that is an immediate finding.

Continuous Compliance vs Annual Assessment

PCI-DSS v4.0 requirement 12.4 makes it explicit: PCI-DSS compliance must be managed as a continuous, ongoing process. The annual Self-Assessment Questionnaire (SAQ) or Report on Compliance (RoC) validates a point in time. What happens in the other 364 days matters just as much.

Configuration drift is the practical risk. Between annual assessments, things change. A new firewall rule gets added to unblock a vendor. An SSID gets created for a temporary event and never removed. A new admin account is provisioned without MFA. A firmware upgrade gets postponed because the business is busy. Each change individually seems minor. Collectively, they erode your compliance posture.

The v4.0 requirement for continuous monitoring means you need a mechanism to detect when your network configuration deviates from a compliant baseline. This is not something you can do manually at scale. If you manage multiple Meraki organisations — as MSPs and multi-site retailers do — checking every firewall rule, every SSID setting, and every admin account across every network on a regular cadence is not feasible without automation.

Automated scanning solves this by running the same compliance checks on a schedule — weekly, monthly, or on demand — and alerting you when a previously passing check starts failing. The drift between scans becomes visible. You catch the new allow-any firewall rule the day after it is added, not eleven months later when the assessor finds it.

The most expensive PCI finding is the one discovered during your annual assessment that has been present for months. Automated scanning turns audit failures into configuration tickets that get fixed in days, not findings that delay your compliance certification.

How to Audit Your Meraki Network for PCI-DSS v4

Whether you use automated tooling or work through the requirements manually, here is the process for auditing a Meraki network against PCI-DSS v4.0.

1. Generate a read-only Meraki API key. Log into the Meraki Dashboard, navigate to your user profile, and generate an API key. This key provides read-only access to your organisation's configuration. It cannot modify any settings, add devices, or change firewall rules. Store it securely — treat it like any other credential.
2. Run a PCI-DSS compliance scan. MerakiGuard connects to your Meraki organisation using the API key, pulls the complete configuration across all networks, and evaluates each setting against the PCI-DSS v4.0 requirements that apply to network infrastructure. The scan takes seconds, not days.
3. Review your compliance scorecard. The scan produces a per-requirement breakdown: pass, fail, or warning for each check. Every result includes the actual configuration value retrieved from the API, so you can see exactly what was checked and why it passed or failed. No black boxes.
4. Remediate failures. Each failing check includes specific remediation guidance. If your L3 firewall is missing a default-deny rule, the report tells you exactly what to configure. If MFA is not enforced organisation-wide, it points you to the setting. Fix the issues in the Meraki Dashboard.
5. Re-scan to verify. After remediation, run another scan to confirm that the changes resolved the findings. This creates an audit trail showing the progression from non-compliant to compliant — evidence your assessor will value.
6. Generate a PDF report. Download a branded PDF report that documents every check, every result, and every evidence value. Hand this to your QSA or use it to complete your SAQ. The report provides the evidence layer that assessors need without the manual screenshot-and-paste process.

For organisations managing multiple Meraki networks, each organisation gets its own scan and scorecard. MSPs can run scans across their entire client portfolio and identify which organisations need attention before assessment season.

The compliance standards that MerakiGuard evaluates go beyond PCI-DSS. If your organisation also needs Cyber Essentials+ certification, NIST, or CIS benchmark validation, the same API key and the same scan covers all of them. One connection, multiple frameworks, continuous evidence.