Notifications
Clear all
Topic starter
10/06/2026 10:56 pm
TL;DR: Manual Cisco Meraki changes to firewall rules, VLANs, VPNs, and traffic policies can leave branches offline or security controls broken, according to ControlMonkey, which argues that versioned backups and point-in-time restore are needed to recover the configuration layer, not just the data layer. The real issue is governance: network configurations are often treated as operational detail even though they now function as identity-adjacent control surfaces.
NHIMG editorial — what this means for NHI practitioners
Questions worth separating out
Q: How should security teams recover Meraki configuration after a bad change?
A: They should restore from a versioned known-good snapshot, then validate firewall rules, VLANs, VPN settings, and traffic shaping before reopening access.
Q: Why do network configuration changes create such a large operational risk?
A: Because network policy controls who can connect, how traffic is segmented, and whether critical sites stay reachable.
Q: What do teams get wrong about backup for office and branch networks?
A: They often back up data carefully but leave configuration history informal or incomplete.
Practitioner guidance
- Inventory Meraki configuration dependencies Map firewall rules, VLANs, VPN settings, and traffic shaping policies to the business services and sites they protect.
- Version the network control plane Keep point-in-time snapshots of critical Meraki settings so teams can compare current state against the last known-good version.
- Link network recovery to identity recovery Test whether restoring identity, cloud, and network configuration together produces a usable environment.
What's in the full announcement
ControlMonkey's full product announcement covers the operational detail this post intentionally leaves for the source:
- The exact Meraki configuration objects covered by the backup workflow, including firewall rules, VLANs, VPN settings, and traffic shaping policies.
- How daily snapshots are used to recreate a known-good branch configuration after accidental change or outage.
- The vendor's comparison of Meraki-only recovery versus broader configuration disaster recovery across cloud, SaaS, identity, and infrastructure.
- The stated workflow for identifying creations, modifications, and deletions before restoring a previous state.
👉 Read ControlMonkey's announcement on Cisco Meraki backup and recovery →
Cisco Meraki backup and recovery: are your configs recoverable?
Explore further
12/06/2026 4:40 am
Network configuration is now an identity-adjacent recovery problem, not just an IT operations task. Meraki firewall rules, VLANs, and VPN settings determine whether users and systems can reach the services they are authorised to use. When those controls are changed or deleted without recovery coverage, the organisation loses the ability to restore access pathways as well as network policy. The implication is that network resilience has to be governed with the same seriousness as access control, because both now shape the practical boundary of enterprise identity.
A few things that frame the scale:
- 19% of organisations give AI systems dramatically more access than human employees, according to The 2026 Infrastructure Identity Survey.
- Only 44% of organisations have implemented any policies to manage their AI agents, even though 92% agree that governing AI agents is critical to enterprise security.
A question worth separating out:
Q: Who is accountable when a Meraki configuration change disrupts access?
A: Accountability usually spans network operations, infrastructure, and security governance because the failure touches availability, access policy, and recovery readiness. The practical test is whether the organisation can show who approved the change, who owns the rollback process, and which controls prevent repeat disruption.
👉 Read our full editorial: Cisco Meraki disaster recovery exposes the network config gap
