Uniqcli

Cisco Meraki MX60 (MX60-HW) Replacement & MX67 Migration

The Meraki MX60 hit Last Day of Support on 2022-10-24 — no firmware, no PSIRT fixes, no RMA. Here is exactly what that means and how to migrate a small branch to the MX67 cleanly.

UT
Uniqcli Team
April 8, 2026 · 7 min read
Share
Cisco Meraki MX60 (MX60-HW) Replacement & MX67 Migration

If you still have a Cisco Meraki MX60 (PID MX60-HW) terminating a branch, the clock has already run out. The MX60 reached End of Sale on October 24, 2015, and its Last Day of Support (LDoS) was October 24, 2022. Everything that makes a security appliance trustworthy — current firmware, PSIRT vulnerability fixes, Cisco TAC, and hardware RMA — ended on that LDoS date. This guide explains what each milestone actually means for a cloud-managed firewall, why the MX67 is the right replacement and what it concretely buys you, and how to migrate a small site with minimal downtime.

What the milestone dates mean for an MX60

Lifecycle dates are not bureaucratic trivia on a security appliance; each one removes a specific protection. Reading them correctly is the difference between a planned refresh and an emergency one.

  • End of Sale (Oct 24, 2015): the last day Cisco sold a new MX60. Anything in service today is at least a decade old, well past the typical hardware MTBF window for a fanless branch appliance, and any unit on the secondary market is unsupportable.
  • End of Software Maintenance (n/a for this PID): on the cloud-managed MX line, firmware is delivered through the Meraki dashboard rather than per-release trains, so there is no separate published software-maintenance milestone — support effectively tracks the LDoS date instead.
  • Last Day of Support / LDoS (Oct 24, 2022): the hard cutoff. After this date the MX60 gets no new firmware, no PSIRT security patches, no Cisco TAC case handling, and no RMA. The dashboard may still manage the device, but Cisco's obligation to fix or replace it is over.

Why acting now matters

The MX60 sits at the security perimeter and terminates VPN, so it is precisely the device an assessor and an attacker both look at first. With firmware frozen at its final pre-LDoS build, there is no path to remediate a newly disclosed vulnerability — your only mitigations are compensating controls bolted on around a box you can no longer patch. Compliance frameworks treat that as unacceptable: continuous-monitoring and configuration-management controls assume the vendor still ships fixes. Beyond audit exposure, the operational risk is blunt. A 2015-era fanless appliance that fails has no RMA path, so a hardware death becomes an unplanned branch outage measured in days of overnight shipping for whatever replacement you can scramble, configured under pressure. Planning the swap now turns that into a scheduled maintenance window.

The current entry-level replacement is the Cisco Meraki MX67 (PID MX67-HW). It keeps everything that made the MX60 attractive for a compact site — a single appliance for firewall, AutoVPN/SD-WAN, content filtering, and traffic shaping, all driven from the same cloud dashboard with zero-touch provisioning — while closing the performance and feature gap that a decade opened up. The migration is unusually low-friction because both generations live in the same Meraki dashboard; you are upgrading the hardware under an interface your team already knows.

What the MX67 concretely improves

  • Throughput: roughly 450 Mbps stateful firewall and about 300 Mbps with the full Advanced Security (UTM) stack engaged, versus roughly 100 Mbps on the MX60 — at the same ~50-user branch sizing. The MX67 can actually run IDS/IPS, AMP, and content filtering on a modern circuit without throttling the site.
  • VPN headroom: around 150 Mbps of site-to-site (AutoVPN) throughput, so a hub-and-spoke or full-mesh SD-WAN of MX67 branches no longer pinches at the tunnel the way the MX60 did, plus modern client VPN including Cisco AnyConnect support on current firmware.
  • Advanced Security: the MX67's Advanced Security license adds Cisco AMP for malware protection, a Cisco Talos-backed IDS/IPS engine, geo-IP firewalling, and Talos-fed content filtering — threat-intelligence layers the MX60 generation never carried.
  • Connectivity and resilience: five Gigabit Ethernet ports plus a dedicated USB port for 3G/4G/LTE failover; the MX67C variant integrates a cellular modem, and the MX67W adds 802.11ac Wave 2 Wi-Fi if the branch needs an all-in-one.
  • Current, supported lifecycle: the MX67 runs the actively maintained MX firmware train and receives PSIRT fixes, restoring TAC and RMA coverage to the perimeter.

A practical migration plan

Because the configuration lives in the dashboard rather than on the appliance, an MX60-to-MX67 swap is one of the cleaner Cisco refreshes — but a few steps keep it from going sideways.

1. Assess and inventory

Pull every MX60 from the dashboard by serial, network name, site, and current firmware. Record the per-site specifics that do not live in a template: WAN circuit type and speed, public IP or NAT-traversal behavior, VLANs and DHCP scopes, static routes, the AutoVPN role (hub vs spoke), and any port-forwarding or 1:1 NAT rules. Note which sites would benefit from the MX67C's integrated LTE rather than relying on a separate failover modem.

2. Sort out licensing

The MX60's license does not migrate to new hardware. Each MX67 needs its own Enterprise or Advanced Security subscription, and you should co-term it to your existing Meraki organization so all appliances renew on a single date. Decide the tier deliberately: if you want the AMP/IDS/IPS/geo-IP stack the MX60 never had, you are buying Advanced Security, not Enterprise. Quote hardware and license together — an MX67 without a current license cannot be added to the dashboard.

3. Confirm config and feature parity

Claim each MX67 by serial into the org, then bind it to the existing dashboard network and swap it for the MX60 in the device list so it inherits firewall rules, content filtering, traffic shaping, and group policies. Map the MX60's port and VLAN assignments onto the MX67's five-port layout, and re-verify any rules that referenced the old appliance's WAN. AutoVPN tunnels re-register automatically once the MX67 checks in and its WAN path is reachable.

4. Plan the physical swap

For a single-appliance branch the physical work is small: same desktop or wall footprint, standard power, and Gigabit copper uplinks — no optics or stacking to size. Where it matters is failover and PoE. The MX line is a security appliance, not a switch, so it does not power downstream devices; anything PoE behind the MX60 stays on the access switch. For cellular resilience, decide between the USB-modem path on the MX67-HW and the integrated radio on the MX67C before you order.

5. Phased cutover

Stage the MX67 on the bench, let it pull its config and firmware from the dashboard, then cut over during a maintenance window: move the WAN and LAN cabling, confirm the appliance comes up green in the dashboard, and validate internet, DHCP, and that AutoVPN tunnels re-establish to the hub and peer spokes. Roll one or two pilot sites first to lock the runbook before fanning out across the fleet.

6. Decommission securely

Once the MX67 is verified in production, remove the MX60 from the dashboard network so it stops counting against licensing, then wipe and physically retire the unit. For regulated environments, follow your media-sanitization and asset-disposal process and capture a certificate of destruction or sanitization for the audit trail. Confirm the MX60's serial is fully released from the org before the hardware leaves the building.

Procurement notes for regulated buyers

For federal, DoD, and SLED programs, source the MX67-HW (and the MX67C/MX67W variants) on TAA-compliant terms and confirm any DoDIN APL requirements before the PO. Uniqcli is an authorized Cisco partner, accepts the Government Purchase Card at micro-purchase thresholds, and quotes the appliance with its co-termed subscription so there are no licensing surprises at deployment. Verify current lead times early — entry MX hardware moves, but subscription co-terming and compliance paperwork add calendar time worth scoping up front. You can review the full lifecycle detail for this PID on our MX60 end-of-life page, browse related dates in the Cisco EoL lookup, and see current MX hardware in the catalog.

Frequently asked questions

My Meraki MX60 still passes traffic — why replace it if it works?

A working MX60 is the dangerous case, because operability hides the real risk. Since Last Day of Support on October 24, 2022, the MX60 receives no firmware updates and no PSIRT security fixes, so any vulnerability disclosed after that date stays open on the box permanently. Cisco TAC will not troubleshoot it and Meraki will not RMA a failed unit. For a perimeter security and VPN appliance, that combination — frozen code on an internet-facing device plus no replacement path if the hardware dies — is exactly what HIPAA, CMMC, and FISMA assessors flag. It works right up until it is the finding in your audit or the entry point in your incident.

Will my MX60 dashboard configuration carry over to the MX67?

Most of it does, and that is the advantage of staying inside the Meraki dashboard. Network-level settings — firewall rules, content filtering categories, traffic shaping, site-to-site (AutoVPN) topology, and group policies — live in the dashboard network, not on the appliance, so you can bind a new MX67 into the same network and inherit them. The practical work is claiming the MX67 by serial, swapping it for the MX60 in the network's device list, and verifying interface, VLAN, and DHCP assignments map to the MX67's port layout. AutoVPN re-establishes automatically once the new appliance checks in and its WAN path is reachable.

What is the throughput difference between the MX60 and the MX67?

It is a large generational jump for a small box. The MX60 was rated around 100 Mbps of stateful firewall throughput and positioned for roughly 50 users. The MX67 delivers about 450 Mbps of stateful firewall throughput, around 300 Mbps with the full Advanced Security (UTM) stack engaged, and roughly 150 Mbps of site-to-site VPN — at the same recommended user count. In practice that means the MX67 can run IDS/IPS, AMP, and content filtering on a modern branch circuit without becoming the bottleneck, which the MX60 could not.

Does the MX67 use the same Meraki licensing as the MX60 did?

The model is the same shape — a mandatory per-appliance annual subscription — but the tiers are modernized. The MX67 is licensed as Enterprise (firewall, AutoVPN, SD-WAN, traffic shaping) or Advanced Security (adds Cisco AMP, IDS/IPS, Talos-backed content filtering, and geo-IP). The MX60's old license does not transfer to new hardware; you buy a fresh MX67 license co-termed to your existing Meraki org so all appliances share one renewal date. Note the MX67 carries its own End-of-Sale milestone now, so size the license term against your intended refresh horizon, not a 10-year hold.

Is the MX67 available on a TAA-compliant, government-payable basis?

Yes. Uniqcli, as an authorized Cisco partner, sources the MX67-HW (and the LTE-integrated MX67C and wireless MX67W variants) on TAA-compliant terms suitable for federal, DoD, and SLED buyers, accepts the Government Purchase Card at micro-purchase thresholds, and can confirm current lead times and any DoDIN APL considerations before you commit a PO. Because the MX67 ships only with a co-termed subscription, we quote hardware and license together so the number you approve is the number that actually deploys.

UT
Written & maintained by

Uniqcli Team

The Uniqcli Team is an authorized Cisco partner specializing in Catalyst wireless, switching, datacenter fabric, licensing, and managed services for U.S. federal, state, local, and education customers. We scope Cisco bills of materials, validate procurement paths (TAA, FIPS, contract vehicles), and deliver design, deployment, and managed operations.

Ready to scope your Cisco build?

Build a quote