Why MSPs Need a Meraki Security Checklist
If you are a managed service provider running Cisco Meraki for your clients, you already know the reality: every organisation has a slightly different configuration, a slightly different set of assumptions about what is "secure enough," and a slightly different appetite for risk. Multiply that across 10, 20, or 50 client orgs and the inconsistency becomes a serious liability.
A structured security checklist eliminates the guesswork. It gives your engineers a repeatable process to follow for every client, every quarter. It ensures that the same baseline is applied whether the org was set up last week or three years ago by someone who has since left the company.
More importantly, the compliance landscape now demands it. Cyber Essentials+ requires evidence of firewall configuration, access control, patch management, and malware protection. PCI-DSS mandates network segmentation and access auditing. Cyber insurance underwriters are increasingly asking for proof that MFA is enforced and firmware is current. If you cannot produce that evidence quickly, you are costing your clients time and money — and exposing your own business to risk.
A good Meraki security checklist is not a nice-to-have. It is the foundation of a professional, defensible managed security service.
The Complete Meraki Security Checklist
This checklist covers every major security domain in a Meraki deployment. Work through each category systematically. If you find items that fail, document them, remediate, and rescan. The goal is not perfection on day one — it is visibility into where every client stands, and a clear path to close the gaps.
Firewall & Network Security
The MX security appliance is your client's perimeter. Misconfigured firewall rules are the single most common finding in Meraki security audits, and they are often invisible until someone actually reads the rule set line by line.
- Default deny on L3 firewall rules. The last rule in the L3 outbound chain should be an explicit deny-all. If the default action is "allow," traffic that does not match any rule passes through unchecked. This is the most critical single check on the entire list.
- No allow-any rules. Look for rules where source, destination, and port are all set to "any" with a policy of "allow." These rules effectively disable the firewall for matching traffic and are usually leftover from troubleshooting sessions that were never cleaned up.
- Audit port forwarding rules. Every port forwarding rule exposes an internal service to the internet. Review each one: is the service still needed? Is the destination host still active? Is the port restricted to the minimum necessary?
- Review 1:1 and 1:Many NAT rules. NAT rules that map public IPs to internal hosts create additional attack surface. Verify that each mapping is intentional, documented, and restricted with appropriate firewall rules.
- Enable IDS/IPS. The MX intrusion detection and prevention system should be set to at least "detection" mode, and ideally "prevention" for production networks. This requires an Advanced Security licence.
- Enable AMP (Advanced Malware Protection). AMP on the MX provides network-level malware scanning. Verify it is enabled and not set to "disabled." Like IDS/IPS, this is part of the Advanced Security licence.
- Configure content filtering. Blocked URL categories should be configured to prevent access to known malicious sites at minimum. Review the allowed and blocked lists to ensure they align with the client's acceptable use policy.
Wireless Security
Wireless networks are the most exposed part of any Meraki deployment. A misconfigured SSID can give an attacker a foothold inside the network without ever touching the physical premises. Every SSID that is broadcasting is a door — make sure each one is locked properly.
- WPA2 or WPA3 on all SSIDs. Every enabled SSID must use WPA2-Enterprise, WPA2-Personal, or WPA3. Open authentication should never be used on any network that carries production traffic.
- No open networks. If the client requires a captive portal for guest access, it should still use WPA2 with a splash page — not an open SSID. Open SSIDs are trivial to impersonate and intercept.
- Guest network isolation. Guest SSIDs must be on a separate VLAN with no access to internal resources. Verify that client isolation is enabled so guest devices cannot communicate with each other.
- Disable unused SSIDs. Meraki supports up to 15 SSIDs per network. Any SSID that is not actively in use should have its enabled status set to false. Broadcasting unused SSIDs increases the attack surface for no benefit.
- 802.1X for corporate SSIDs. The primary corporate SSID should use WPA2/WPA3-Enterprise with RADIUS authentication. This ties wireless access to individual user credentials rather than a shared PSK, enabling proper access auditing and revocation.
- No default SSID names. SSIDs still named "Unconfigured SSID" or using Meraki default names indicate incomplete setup. Rename them or disable them. Default names also leak information about the hardware vendor to attackers.
Access Control
Admin access to the Meraki dashboard is the keys to the kingdom. If an attacker compromises a full org admin account, they can modify firewall rules, disable security features, and exfiltrate configuration data — all without touching a single device. This is where most organisations fail their first compliance assessment.
- Enforce org-wide MFA. The Meraki dashboard has an organisation-level setting to enforce two-factor authentication for all administrators. If this is not enabled, every admin account without MFA is a compliance failure and a real security risk.
- Remove stale admin accounts. Audit the admin list for accounts that have not logged in within your policy window (typically 90 days). Former employees, departed contractors, and test accounts should be removed immediately.
- Least-privilege roles. Not every administrator needs full org admin access. Use Meraki's role-based access to grant network-specific or read-only permissions where appropriate. The principle of least privilege is a core requirement of every major compliance framework.
- No shared or generic admin accounts. Every admin should be an individual, identifiable user with a unique email address. Shared accounts like "admin@company.com" or "helpdesk@msp.com" make it impossible to attribute changes and violate audit trail requirements.
- Audit API keys. API keys grant programmatic access to the full organisation. Review which users have generated API keys, and revoke any that are no longer needed. API keys should be treated with the same sensitivity as admin passwords.
Patch Management
Meraki's cloud-managed firmware model simplifies patching compared to traditional networking equipment, but it does not eliminate the need for oversight. Firmware updates still need to be scheduled, verified, and tracked — especially across a large MSP portfolio where different clients may have different upgrade policies.
- Firmware current across all device types. Check MX appliances, MR access points, MS switches, MV cameras, and any other Meraki hardware. Compare running firmware versions against the latest stable release. Devices more than one major version behind should be flagged for immediate attention.
- No offline devices. A device that is offline cannot be patched, monitored, or managed. Identify any devices showing as offline in the dashboard and determine whether they are decommissioned (and should be removed) or disconnected (and need remediation).
- Upgrade schedule configured. Meraki allows you to set firmware upgrade windows per network. Verify that each client network has a defined upgrade schedule rather than relying on manual upgrades. This ensures patches are applied consistently without requiring engineer intervention for every update.
Network Segmentation
Flat networks are a compliance failure and a security risk. If a compromised device on the guest Wi-Fi can reach the payment terminal or the domain controller, segmentation has failed. Proper VLAN architecture is foundational to PCI-DSS, Cyber Essentials, and virtually every other security framework.
- VLANs separating guest, corporate, IoT, and management traffic. At minimum, guest devices, corporate endpoints, IoT devices (printers, cameras, sensors), and management interfaces should be on separate VLANs. Each VLAN should have its own subnet and DHCP scope.
- Inter-VLAN firewall rules. Creating VLANs without firewall rules between them provides no security benefit. Verify that MX inter-VLAN firewall rules are in place to restrict traffic between segments. The default should be deny, with explicit allow rules only for required traffic flows.
- PCI scope isolation. If the client processes card payments, the cardholder data environment (CDE) must be isolated from all other network segments. Verify that the PCI VLAN has no routes to guest, IoT, or general corporate networks. This is a hard requirement of PCI-DSS and is frequently the reason organisations fail their first assessment.
Monitoring & Logging
Security controls are only useful if you know when they are triggered or bypassed. Monitoring and logging provide the visibility layer that turns a configured network into a managed one. Without logs, you are flying blind — and you will have nothing to show an auditor or insurer when they ask how you detected (or failed to detect) an incident.
- Syslog configured. Meraki devices can forward logs to an external syslog server. Verify that syslog is enabled and pointing to a functioning collector. Log retention should meet the client's compliance requirements — typically 12 months for CE+ and PCI-DSS.
- SNMP with strong community strings. If SNMP is enabled for monitoring, verify that the community strings are not set to "public" or "private." Use SNMPv3 where possible for encrypted, authenticated polling. If SNMP is not needed, disable it entirely.
- Alerts configured for critical events. Meraki supports email alerts for events such as device going offline, rogue AP detection, VPN connectivity loss, and configuration changes. Verify that alerts are enabled and being sent to a monitored mailbox or ticketing system — not an unmonitored inbox.
How Often Should You Run This Checklist?
The short answer: monthly at minimum. Configuration drift is constant. Engineers make changes, clients request exceptions, firmware updates introduce new defaults. A network that passed every check last month can fail three of them this month because someone added a port forwarding rule during a troubleshooting session and forgot to remove it.
Beyond the monthly cadence, you should also run the checklist:
- After any significant network change. New site deployment, VPN tunnel addition, SSID modification, admin account creation — any change that touches the security posture should trigger a rescan.
- Before any compliance assessment. Whether it is a Cyber Essentials+ renewal, a PCI-DSS audit, or a cyber insurance renewal questionnaire, run the checklist before the assessor arrives. Finding problems in advance gives you time to fix them.
- After onboarding a new client. The first scan of a new client's Meraki environment is almost always the most revealing. Inherited networks carry inherited technical debt. Run the full checklist before you accept operational responsibility.
The challenge, of course, is that running this checklist manually does not scale. Logging into each client's Meraki dashboard, navigating through every configuration page, and documenting each finding takes hours per organisation. If you manage 20 clients, a monthly manual audit cycle is effectively a full-time job. That is not sustainable, and it is not necessary.
Automating the Checklist with MerakiGuard
Every item on this checklist maps directly to a check in MerakiGuard. The Meraki Dashboard API exposes all of the configuration data needed to evaluate firewall rules, SSID settings, admin accounts, firmware versions, VLAN configuration, and monitoring setup — programmatically, without logging into the dashboard.
The workflow is simple:
- Connect your Meraki org with a read-only API key. MerakiGuard never writes to or modifies your network configuration.
- Run a scan. MerakiGuard pulls the full configuration via API and evaluates every setting against the checklist — mapped to Cyber Essentials+, PCI-DSS, NIST, and CIS benchmarks.
- Get instant results. A compliance scorecard with pass/fail for every check, evidence values showing exactly what was found, and remediation guidance for every failure.
For MSPs, the critical advantage is scale. You can run this across every client organisation from a single dashboard. Instead of logging into 20 separate Meraki orgs and clicking through configuration pages, you get a portfolio-wide view of which clients are compliant and which are not — sorted by score, filterable by standard, with full audit trails.
Scans that would take your team hours to complete manually run in under two minutes. Monthly compliance cycles that consumed days of engineering time become something you can do before your morning coffee.
Turning Security Audits Into MSP Revenue
Here is the opportunity most MSPs are missing: compliance scanning is a service your clients will pay for. It is not just an internal efficiency tool — it is a product.
Your clients need compliance evidence. They need it for Cyber Essentials certification, for PCI-DSS assessments, for cyber insurance renewals, and increasingly just for basic due diligence when onboarding enterprise customers. Today, most of them get that evidence by asking you to spend days producing it manually — time that either goes unbilled or gets buried in your managed service agreement at a loss.
With automated tooling, you can repackage that same output as a paid, recurring service:
- Monthly compliance reports delivered to each client, branded with your logo, showing their security posture against the standards that matter to their business.
- Pre-audit preparation as a fixed-fee engagement before each client's CE+ or PCI-DSS assessment. Run the scan, identify failures, remediate, rescan, and hand the client a clean report to give their assessor.
- Continuous compliance monitoring as a premium tier in your managed service offering. Clients who need ongoing evidence — regulated industries, government contractors, financial services — will pay for the assurance that their network is being audited consistently.
- New client assessments as part of your onboarding process. The first scan of a prospect's Meraki network often reveals enough issues to justify the engagement on its own.
The maths works in your favour. A manual audit that takes two days of engineer time costs you hundreds of pounds in labour. An automated scan that takes two minutes and produces the same (or better) output can be sold as a service at a healthy margin. You deliver more value to the client, at a lower cost to you, with better consistency than manual processes can achieve.
Compliance is not going away. The regulatory environment is getting stricter, insurance requirements are getting more specific, and your clients are being asked for evidence more frequently. MSPs that build automated compliance scanning into their service offering now will have a structural advantage over those that are still taking screenshots in 2027.
Every Meraki network you manage is a compliance engagement waiting to happen. The question is whether you are capturing that revenue or leaving it on the table.