Mapping NIST CSF to Your Cisco Meraki Network

Why NIST CSF Matters for Network Teams

The NIST Cybersecurity Framework was originally developed for US federal agencies and critical infrastructure operators. That was 2014. A decade later, NIST CSF has become the de facto cybersecurity risk management framework adopted by organisations worldwide — regardless of whether they have any obligation to a US government agency.

The reason is straightforward: boards and executive teams understand it. The five core functions — Identify, Protect, Detect, Respond, Recover — provide a language for cybersecurity posture that translates across technical and non-technical audiences. When a CISO presents a scorecard organised by these five functions, the board does not need a networking background to understand where the organisation is strong and where it is exposed.

NIST CSF also maps cleanly to other frameworks your organisation may already be working with. ISO 27001 control objectives align with NIST CSF subcategories. SOC 2 trust service criteria overlay onto the same structure. If you are pursuing multiple certifications or responding to customer security questionnaires, NIST CSF acts as the connective tissue between them all.

For network teams managing Cisco Meraki infrastructure, this creates a specific challenge: how do you demonstrate that your network configuration — the firewall rules, SSID settings, firmware versions, and access controls you manage every day — actually maps to these abstract framework functions? The answer lies in the Meraki Dashboard API and a systematic approach to mapping subcategories to configuration data.

The Five Core Functions and Your Meraki Network

NIST CSF organises cybersecurity activities into five concurrent and continuous functions. Each one has a direct relationship with specific Meraki configuration areas. Here is how they map.

Identify

The Identify function is about understanding your environment. You cannot protect what you do not know exists. This covers asset management, business environment awareness, governance, risk assessment, and risk management strategy.

For Meraki networks, Identify starts with the device inventory API. Every MX appliance, MR access point, MS switch, MV camera, and MG cellular gateway in your organisation is catalogued in the Meraki dashboard with its model, serial number, firmware version, network assignment, and online status. The network topology endpoints expose how these devices connect, which VLANs they serve, and what subnets they manage.

This is the foundation everything else builds on. If your asset inventory in Meraki does not match your actual deployed hardware, every subsequent compliance assessment is built on incomplete data. Automated scanning catches this — offline devices, unclaimed hardware, networks with no devices assigned.

Protect

The Protect function covers the safeguards you put in place to limit the impact of a cybersecurity event. This is where most of your Meraki configuration lives: access control, data security, information protection processes, maintenance, and protective technology.

On a Meraki network, Protect maps to a broad set of configuration areas:

• Firewall rules — L3 and L7 firewall policies on MX appliances, including default-deny posture for inbound traffic and least-privilege rule sets
• SSID encryption — WPA3 or WPA2-Enterprise on wireless networks, with open or WPA-Personal SSIDs flagged as non-compliant
• Administrator MFA — organisation-wide enforcement of two-factor authentication for all dashboard administrator accounts
• Firmware patching — devices running current, vendor-supported firmware with security patches applied within policy windows
• VLAN segmentation — proper network segmentation isolating guest traffic, IoT devices, and management networks from production environments

Protect is typically the strongest function for Meraki-managed networks because it maps directly to the configuration settings that network engineers interact with daily. The gap is usually not that the settings are wrong — it is that nobody has systematically verified them against a framework.

Detect

The Detect function covers the activities needed to identify cybersecurity events in a timely manner. This includes anomaly detection, continuous security monitoring, and detection processes.

Meraki provides several detection capabilities through the MX security appliance:

• IDS/IPS — Intrusion Detection and Prevention System using Snort-based rulesets. Can operate in detection-only or prevention mode. The API exposes whether this is enabled and at what sensitivity level.
• Syslog and SNMP — event logging to external collectors. The API reveals whether syslog servers are configured, which event categories are forwarded, and whether SNMP is enabled with appropriate community strings.
• Event logging — the Meraki dashboard maintains event logs for configuration changes, security events, and client activity. These are accessible via API for auditing and correlation.
• Advanced Malware Protection (AMP) — file reputation and sandboxing at the network edge. The API confirms whether AMP is active and in what mode.

Detect is where many Meraki deployments fall short. The capabilities exist in the product, but they are not always enabled. A Meraki MX with an Advanced Security licence has IDS/IPS and AMP available, but if nobody turned them on during deployment, the Detect function has a gap.

Respond

The Respond function covers what happens when a cybersecurity event is detected. This includes response planning, communications, analysis, mitigation, and improvements to the response process.

Meraki's contribution to the Respond function is primarily about visibility and configuration:

• Alert configuration — the Meraki dashboard supports alerts for device status changes, configuration changes, usage thresholds, and security events. The API exposes which alerts are configured and who receives them.
• Change logs — every configuration change in the Meraki dashboard is logged with a timestamp, the administrator who made the change, and what was modified. This provides the forensic trail needed during incident response.
• Incident visibility — security event data from IDS/IPS, AMP detections, and content filtering blocks are all available via API for correlation with external SIEM or incident management tools.

Respond is not something a network configuration tool can fully satisfy — it requires documented processes, communication plans, and human decision-making. But the network infrastructure needs to provide the telemetry and alerting that makes those processes effective.

Recover

The Recover function focuses on restoring capabilities or services that were impaired during a cybersecurity event. This includes recovery planning, improvements, and communications.

For Meraki networks, Recover maps to:

• Firmware rollback capability — the ability to revert to a previous firmware version if an update causes issues or if a compromised device needs to be restored to a known-good state
• Configuration backup — Meraki's cloud-managed model means device configurations are stored centrally. The API allows you to read the full configuration of any device, which can be documented and used as a restoration baseline.
• Documented baseline — knowing what "good" looks like is essential for recovery. A compliance scan against NIST CSF creates a documented baseline of your expected configuration state, so when something changes, you know exactly what to restore.

Recover is the function most organisations handle least well. Everyone focuses on building walls (Protect) and watching for intruders (Detect), but few teams have a documented, tested recovery process for their network infrastructure.

Mapping Table: NIST CSF Subcategories to Meraki API

The five functions break down into categories and subcategories. Here are ten key subcategories with direct Meraki API mappings and what to check for compliance.

This is not an exhaustive mapping — NIST CSF contains over 100 subcategories, and many of them relate to organisational processes rather than technical controls. But these ten represent the subcategories where Meraki network configuration provides direct, auditable evidence.

Common Gaps in Meraki NIST Alignment

After analysing hundreds of Meraki configurations, patterns emerge. The same gaps appear repeatedly, and they cluster around two of the five functions.

Detect is consistently the weakest function. The most common finding is that IDS/IPS is available but not enabled. Organisations purchase the Advanced Security licence for content filtering but never configure the intrusion detection features. Syslog forwarding is another frequent gap — without it, security events exist only in the Meraki dashboard's 30-day rolling log with no long-term retention or external correlation.

Recover is the most neglected function. Very few organisations have a documented network recovery process. They trust that Meraki's cloud management means the configuration is always available, which is true — but they have never tested whether they can rebuild their network from that configuration data. When the question is "how quickly can you restore your network to a known-good state after a compromise?", silence is the most common answer.

Within the Protect function, the specific gaps tend to be:

• MFA not enforced org-wide — individual admins may have MFA enabled, but the organisation-level enforcement toggle is off, meaning new admins can be created without it
• Open or WPA-Personal guest SSIDs without proper isolation — the SSID exists for convenience, but the VLAN segmentation and firewall rules to isolate it from production traffic are incomplete
• Firmware one or more versions behind — not critically out of date, but not current either. This accumulates over time when firmware upgrades are not part of a scheduled maintenance process

Continuous Monitoring vs Point-in-Time Assessment

One of the most important things to understand about NIST CSF is that it was designed as a living framework, not a point-in-time certification. Unlike Cyber Essentials, which has an annual assessment date, NIST CSF describes an ongoing posture that should be continuously measured and improved.

This distinction matters for how you approach compliance. A point-in-time assessment tells you where you stood on a specific date. Continuous monitoring tells you where you stand right now — and alerts you when something changes.

For Meraki networks, configuration drift is the primary risk between assessments. A firewall rule is added to troubleshoot a connectivity issue and never removed. An admin account is created for a contractor who left three months ago. A new SSID is deployed for an event and forgotten. Each of these changes individually might be minor, but cumulatively they degrade your NIST CSF posture without anyone noticing.

Quarterly reviews should be the minimum cadence. Monthly is better. Automated scanning enables continuous posture assessment — run a scan after every change window, or schedule them weekly, and compare scores over time. The trend matters as much as the absolute number.

The organisations that score highest against NIST CSF are not the ones with the most expensive security tools. They are the ones with consistent visibility into their own configuration and a process for acting on what they find.

How MerakiGuard Maps to NIST CSF

We built MerakiGuard to address exactly this challenge. Rather than manually cross-referencing Meraki configuration pages against framework subcategories, MerakiGuard connects to your Meraki organisation via a read-only API key and automatically evaluates your configuration against compliance standards — including NIST CSF.

MerakiGuard checks span all five NIST CSF functions:

• Identify — device inventory completeness, network assignments, offline device detection
• Protect — firewall posture, SSID encryption, MFA enforcement, firmware currency, VLAN segmentation
• Detect — IDS/IPS status, AMP configuration, syslog forwarding, SNMP settings
• Respond — alert configuration, notification recipients, change log availability
• Recover — configuration baseline documentation, firmware rollback readiness, device status monitoring

Each function receives its own score, so you can see at a glance where your Meraki network is strong and where it needs attention. The per-check results include the specific configuration values found, what the framework expects, and actionable remediation guidance for every failure.

NIST CSF is one of four compliance standards MerakiGuard supports, alongside Cyber Essentials+, PCI-DSS, and CIS Benchmarks. If your organisation reports against multiple frameworks, a single scan produces scores against all of them — because the underlying Meraki configuration data is the same, only the compliance lens changes.

No agents. No firewall changes. No write access to your network. Connect a read-only API key, run a scan, and see exactly how your Meraki infrastructure maps to NIST CSF.