Cisco Meraki MX64 EoL: Migration to the MX67

If your small branches, clinics, or remote sites still run the Cisco Meraki MX64 (PID MX64-HW), the clock on that hardware is now visible. The MX64 went End of Sale on July 26, 2022, and its Last Day of Support (LDoS) is July 26, 2027. The appliance still terminates VPN tunnels and passes traffic today, which is precisely why so many of them stay racked long after the procurement record says they should have been replaced. This guide explains what the MX64's lifecycle dates mean for a fleet you actually operate, why the recommended Meraki MX67 is a genuine generational upgrade rather than a cosmetic swap, and how to plan a migration that holds your security posture and compliance evidence intact.

What the Meraki MX64 actually was

The MX64 was Meraki's entry-class cloud-managed security and SD-WAN appliance for small branches and teleworker sites, typically rated for roughly 50 users. It is a fanless desktop unit with five 1GbE RJ45 ports (one dedicated WAN/Internet port plus four LAN ports), no PoE, and no integrated wireless on the base SKU. Its published stateful firewall throughput is about 250 Mbps, with advanced security (IPS/IDS, content filtering, AMP, anti-malware) throughput closer to 100 Mbps, and a site-to-site AutoVPN ceiling in the same low-hundreds-of-Mbps range. Everything about it (firewall rules, Auto VPN, SD-WAN policy, client VPN, Advanced Malware Protection, Snort-based IPS, group policies) is configured in the Meraki dashboard and licensed per device, per year, in either the Enterprise or the Advanced Security tier. There is no on-box CLI to manage; the cloud is the management plane. That model is the MX64's strength and, at end of life, its constraint: when Meraki stops shipping firmware for a hardware generation, the dashboard eventually moves past it.

Why acting now matters

The risk of an end-of-life security appliance is not that it dies. It is that it keeps inspecting traffic while the support floor quietly disappears underneath it. Three exposures stack up as LDoS approaches and passes:

• No security or firmware fixes. The MX64 is a perimeter security device, a firewall, IPS, VPN concentrator, and content filter in one box. After LDoS, a newly disclosed vulnerability in the firmware, the VPN stack, or the IPS engine on this hardware generation will not get a patched build. On a device whose entire job is to stop attacks, an unpatchable defect is the worst possible place to carry it.
• No TAC or RMA. Once past LDoS you cannot open a support case or get an advance-replacement unit for an MX64 that fails. For a branch where the MX is the only path to the WAN and to AutoVPN, a dead appliance with no RMA means an outage measured in days while you source secondary-market hardware of the same dead-end model.
• Audit and compliance exposure. Federal, DoD, SLED, healthcare, and PCI environments are expected to run supported, patchable security infrastructure. FedRAMP, CMMC, the HIPAA Security Rule, PCI DSS, and CISA directives all assume the vendor still ships fixes. 'The appliance is past Last Day of Support and can no longer be patched' is not a defensible answer to an assessor, and an EoL firewall is a finding waiting to be written.

There is also a dashboard trap unique to the cloud-managed model. As Meraki advances firmware trains (MX 18.x and later) and adds capabilities, older hardware like the MX64 either lags behind or is excluded from the newest stable builds. You can end up unable to adopt a feature or a fix your security team needs simply because the silicon predates it, without the option of buying your way onto a newer image, because the image does not exist for that box.

What each milestone date means in practice

• End of Sale (2022-07-26): the last day Cisco/Meraki accepted new MX64 orders. Everything after this date is consuming the support tail you already paid for.
• Last Day of Support / LDoS (2027-07-26): the hard wall. No TAC, no advance-replacement RMA, and no firmware or security patches for the MX64 hardware after this date. Active dashboard licenses on the device do not extend support past it; a licensed but unsupported appliance is still unsupported.
• The practical planning horizon: treat LDoS minus your procurement and rollout lead time as the real deadline. For a multi-site fleet on government contract vehicles, that means starting well before mid-2027, not at it.

The recommended replacement: Meraki MX67

Cisco names the Meraki MX67 (PID MX67-HW) as the functional replacement for the MX64, and it is the same form factor and same dashboard-managed experience, but with materially more headroom and a modernized feature set. The MX67 is built for the same small-branch and teleworker role (roughly 50 users), so the deployment story stays simple while the ceilings rise:

• Higher throughput with room to grow. The MX67 raises stateful firewall throughput to roughly 450 Mbps and advanced-security (full IPS/AMP/content-filtering) throughput to about 300 Mbps, versus the MX64's ~250 Mbps firewall / ~100 Mbps secured. As branch internet circuits have grown from tens of Mbps to several hundred, the MX64 increasingly became the bottleneck that throttled the link you pay for; the MX67 removes that.
• More capable ports and failover. The MX67 keeps the five-port 1GbE RJ45 layout (1 WAN + 4 LAN) but adds a dedicated USB port for a 4G/LTE cellular failover modem, giving small sites true out-of-band WAN redundancy that the base MX64 lacked.
• Modern firmware and longer runway. The MX67 runs current MX firmware trains and will continue receiving security and feature updates long after the MX64 stops. You move from a hardware generation aging out of the dashboard to one squarely in active development.
• PoE and integrated-wireless variants. The MX67 family includes the MX67C (integrated CAT 6 LTE modem) and MX67W (integrated 802.11ac Wave 2 Wi-Fi), so a single box can cover routing, security, cellular failover, and access at a micro-site. Note the trade-off: the base MX67, like the MX64, does not supply PoE, so plan power for any IP phones or cameras accordingly.
• Same licensing model, cleaner transition. The MX67 uses the same per-device Enterprise and Advanced Security dashboard license tiers as the MX64, so your team's operational model, policy templates, and security feature set carry straight across. Advanced Security still gets you IPS, AMP, content filtering, and geo-IP firewalling.

A practical migration plan

Because the MX64 is cloud-managed, a migration is more about configuration portability and license accounting than console cabling, but the rigor still matters, especially across many sites and under a compliance regime. Work it in phases.

1. Assess and inventory

Pull every MX64 from the Meraki dashboard organization inventory and export serials, network bindings, firmware versions, and current license type and expiry. Map each appliance to its physical site, its WAN circuit and bandwidth, and any cellular or PoE dependencies. Flag sites whose internet speed already exceeds the MX64's secured throughput; those are your highest-priority swaps, because they are losing performance you are paying for every day.

2. Plan the license transition

Meraki licensing is tied to hardware in the dashboard, so each MX67 needs its own Enterprise or Advanced Security license claimed into the organization. Decide between co-termination and per-device licensing before you order, and align the MX67 license terms with your existing renewal date so you are not double-paying during overlap. Keep the MX64 licensed and online during cutover; you decommission the license only after the MX67 is verified in production.

3. Establish config and feature parity

In the dashboard, clone the MX64 network's configuration onto the MX67 network: firewall and outbound rules, VLANs and addressing, AutoVPN hub/spoke membership and SD-WAN traffic-shaping policies, client VPN settings, content-filtering categories, IPS ruleset mode, and group policies. Confirm the MX67 firmware train supports every feature the site relies on (it will support more, not fewer). Because both are dashboard-managed, much of this is template reuse rather than re-keying CLI, but validate AutoVPN registration and IPS/AMP behavior explicitly, since those are the security functions an assessor will ask about.

4. Handle the physical and WAN details

The MX67 is the same desktop form factor, so rack or shelf placement is essentially one-for-one. Verify the WAN handoff (the MX67 WAN port is 1GbE RJ45), confirm you have the LAN ports you need (still four), and plan power for any device that drew PoE elsewhere, since neither base unit supplies it. If the site needs WAN redundancy, this is the moment to add a USB LTE modem to the MX67, or to specify an MX67C with the modem integrated, capability the MX64 could not match.

5. Phased cutover

Stage each MX67 by claiming it into the organization, letting it pull configuration and firmware over the network, then swapping it in during a maintenance window: physically connect WAN and LAN, confirm the device comes online green in the dashboard, validate AutoVPN tunnels re-establish to the hubs, and test client VPN and internet egress before you leave the site. Start with a low-risk pilot site, prove the runbook, then fan out across the fleet.

6. Securely decommission the MX64

After the MX67 is confirmed in production, remove the MX64 from the dashboard network, then unclaim it from the organization so its license and serial are cleared. For federal, DoD, and healthcare sites, wipe and dispose of the hardware under your data-sanitization standard (NIST SP 800-88 media handling for the configuration store), and record the disposal in your asset register so the EoL device is provably out of the environment for the next audit.

Procurement notes for regulated buyers

Because the MX64 went End of Sale in 2022, new units are not orderable from Cisco, so sourcing the MX67 (and verifying it is genuine, warrantied, and license-eligible) should go through an authorized partner. For US federal, DoD, and SLED buyers, confirm TAA compliance and country-of-origin on the MX67-HW for GSA and contract-vehicle eligibility, and account for current lead times when you scope the LDoS deadline: hardware plus license plus rollout time, not just the appliance ship date. As an authorized Cisco partner serving regulated customers, uniqcli can confirm availability, structure the license co-term, and quote the MX67 against your specific site count. Browse current Meraki and security hardware in our catalog, review the full milestone record on the MX64 EoL detail page, or see all the lifecycle guides in our Cisco EoL hub. When you are ready to scope the refresh, get a quote and we will size MX67 licensing and hardware to your branch fleet.