Cisco Meraki MX65 EoL: Migration to the Meraki MX68

If you still have Cisco Meraki MX65 appliances (PID MX65-HW) terminating the internet circuit at branch offices, the clock on them is nearly out. The MX65 reaches its Last Day of Support (LDoS) on May 28, 2026. From that date forward, Cisco Meraki provides no further firmware releases, no PSIRT security fixes, no TAC support cases, and no RMA hardware replacement for this model. The appliance will keep routing packets and enforcing its last-known ruleset, which is precisely the trap: a perimeter security device that looks healthy on the dashboard while quietly becoming unpatchable. This guide explains what the milestone actually means for a live branch, why the recommended Meraki MX68 is a genuine step up rather than a like-for-like box, and how to plan a clean cutover with no gap in protection or SD-WAN connectivity.

What the Meraki MX65 actually was

The MX65 was Cisco Meraki's small-branch security and SD-WAN appliance, positioned for offices of roughly 50 users. It is a fully cloud-managed unified threat management (UTM) box: there is no local CLI to speak of, no on-box management plane, and no controller — every policy, VPN tunnel, and firmware push comes from the Meraki dashboard. Physically it carries 12 Gigabit Ethernet ports: 2 dedicated WAN ports for dual-uplink load balancing and failover, plus 10 LAN ports, of which 2 are 802.3at PoE+ capable to power a downstream AP, phone, or camera directly. Recommended throughput sat around 250 Mbps of stateful firewall and roughly 100 Mbps of Auto VPN (site-to-site IPsec) performance. It delivered the standard Meraki MX feature set: stateful L3/L7 firewall, Auto VPN SD-WAN, client and site-to-site VPN, and — with the Advanced Security license — Sourcefire-based IDS/IPS, Cisco AMP for malware, and category-based content filtering.

Two design facts matter for the refresh. First, the MX65 is hardware-locked to a Meraki license; the box is inert without an active subscription, so there is no 'run it unlicensed for a while' option. Second, all real capability — throughput ceilings, IDS/IPS signatures, AMP — is gated by both the hardware generation and the license edition. The MX65 hardware is the limiting factor that LDoS now forces you to address.

Why acting now matters

The danger of an end-of-life firewall is not that it fails. It is that it keeps enforcing policy while the support and patch floor vanishes beneath it. After May 28, 2026, three exposures stack up on the MX65:

• No PSIRT or firmware security fixes. Meraki MX firmware is delivered centrally from the cloud, but an LDoS appliance is removed from the supported firmware track. When a new vulnerability lands in the firewall, VPN, or UTM code path, the MX65 will not receive the fixed build. For an internet-facing device, that is a permanent, unpatchable hole on the exact box meant to stop attacks.
• No TAC or RMA. You cannot open a support case for an MX65 after LDoS, and a dead unit cannot be swapped under warranty or contract. Your only recovery is a cold spare you bought before the date or a secondary-market unit of the same dead-end model — at a remote branch, that can mean days of outage.
• Audit and compliance exposure. Federal, DoD, SLED, and healthcare buyers operate under FedRAMP, CMMC, the HIPAA Security Rule, PCI DSS, and CISA directives, all of which expect supported, patchable perimeter security. An unsupported branch firewall is a documented finding, and 'the vendor no longer issues fixes' is not a defensible remediation plan to an assessor.

What each milestone means in practice

• End of Sale (2019-05-28): the last day Cisco Meraki accepted new MX65 orders. Everything since has been consuming the support tail.
• End of Software Maintenance: not published as a separate date for the MX65. Because Meraki firmware is cloud-delivered rather than per-device branch builds, meaningful software support effectively runs to LDoS.
• Last Day of Support / LDoS (2026-05-28): the hard wall. No firmware, no security fixes, no TAC, no RMA. The appliance is on its own from that day.

The recommended replacement: Meraki MX68 (and the MX68W variant)

Cisco names the Meraki MX68 (PID MX68-HW) as the direct successor to the MX65, and for sites that also need on-box Wi-Fi the MX68W carries an integrated 802.11ac Wave 2 radio. The MX68 keeps the small-branch footprint and dashboard workflow you already know, so the operational learning curve is near zero, but the hardware generation is meaningfully stronger. Where it improves on the MX65:

• Higher throughput headroom. The MX68 roughly doubles the MX65's ceilings — on the order of 450 Mbps of stateful firewall throughput and around 250 Mbps of Auto VPN — so branches that have outgrown a 250 Mbps box during the appliance's life are no longer bottlenecked by the firewall. UTM features (IDS/IPS, AMP, content filtering) stay usable at higher line rates instead of throttling the circuit.
• Native cellular failover. The MX68 adds a built-in USB port for a Meraki-validated LTE modem, giving you a genuine out-of-band uplink for true SD-WAN failover at a branch without a second wired ISP — something the MX65 could only approximate with an external workaround.
• Same port and PoE profile, refreshed silicon. The MX68 retains 12 ports (2 WAN, 10 LAN) with 2 PoE+ (802.3at) ports, so your existing wiring, downstream PoE devices, and uplink design carry over one-for-one. The newer CPU and crypto path also handle modern TLS-heavy traffic and larger Auto VPN meshes more comfortably.
• Integrated Wi-Fi option (MX68W) and PoE+ uplink models (MX68CW with embedded LTE). For very small or single-closet branches, the MX68W collapses firewall, SD-WAN, switching, and wireless into one cloud-managed box, reducing the device count you have to license and patch.

Both run the same Meraki dashboard, the same Auto VPN SD-WAN fabric, and the same Advanced Security feature set, so feature parity with the MX65 is a given — you are gaining capacity and a cellular uplink, not relearning the product. If you want to confirm current MX68 availability, configuration, and TAA status, our catalog lists the SKUs we stock and source.

A practical migration plan

Because both appliances live entirely in the Meraki dashboard, an MX-to-MX refresh is one of the cleaner migrations in the Cisco portfolio — but it still rewards a methodical, branch-by-branch approach rather than a swap-and-pray.

1. Assessment and inventory

Pull every MX65 from your Meraki organization by network, branch, WAN circuit speed, and current firmware. Note which sites use the PoE+ ports and what they power, which use a second WAN uplink, and which depend on Auto VPN spoke roles. Capture each site's real throughput against the MX65's 250 Mbps ceiling — branches running near the limit justify the MX68's higher headroom on their own. Record the organization's license co-termination date; you will align new licenses to it.

2. License transition

Meraki licensing is per-device and co-term based, not transferable between models, so each MX68 is licensed in its own (same small-branch) size class. Decide the edition per site: Enterprise covers SD-WAN, the L3/L7 firewall, and VPN; Advanced Security adds the IDS/IPS, AMP malware protection, and content filtering many compliance regimes require. Match what the MX65 runs today unless you are deliberately upgrading coverage, and align the new term to your existing co-term date so renewals stay consolidated.

3. Configuration and feature parity

In the dashboard, you can add the MX68 to the same network and, for most branches, replicate the MX65's VLANs, firewall rules, traffic shaping, and VPN settings cleanly because the configuration model is identical across MX hardware. Validate the few items that touch hardware specifics — PoE port assignments, any per-uplink shaping tied to the MX65's WAN ports, and Auto VPN hub/spoke roles. Stage the configuration before the physical swap so the box is policy-ready the moment it joins.

4. Physical: rack, power, PoE, uplinks

The MX68 is a near drop-in for the MX65: same desktop/rack footprint, same 12-port layout, same 802.3at PoE+ on two ports, and standard RJ45 Gigabit uplinks (no optics to re-source for the base model). Reuse existing patch cabling and PoE loads. If you are adopting cellular failover, provision the validated USB LTE modem and SIM ahead of the cutover so the second uplink is live on day one.

5. Phased cutover

Pilot one representative branch first. With the MX68 pre-staged in the dashboard, the cutover is largely a cabling swap during a short maintenance window: move WAN and LAN connections, let the appliance pull its config and firmware from the cloud, confirm Auto VPN tunnels re-establish to the hub, and verify client traffic and UTM logging. Once the pilot is clean, roll the remaining branches in waves rather than all at once, keeping a known-good rollback (the MX65) on hand until each site is confirmed.

6. Secure decommission

Do not let retired MX65s walk out the door with live config. In the dashboard, remove each unit from the network so it can no longer pull policy or VPN keys, then factory-reset the hardware to clear local state. For federal, DoD, and healthcare environments, document the wipe and dispose of or return units per your data-handling policy. Removing the device from the organization also stops it consuming a license slot.

Procurement notes for regulated buyers

For US federal, DoD, and SLED purchases, confirm Trade Agreements Act (TAA) compliance and country-of-origin on the MX68 SKUs, and buy through an authorized Cisco partner so warranty, license registration, and support entitlement attach correctly to your organization. MX68 hardware and Meraki licensing can carry lead times, especially in volume across many branches, so place orders well ahead of the May 28, 2026 LDoS rather than against it. Government purchase card (GPC) and contract-vehicle orders are straightforward to structure, but the license co-term and edition need to be set at order time, not after delivery.

See the full milestone detail and source dates on the MX65 EoL page, browse the wider list of affected models on the Cisco EoL hub, and when you are ready to size the refresh, get a quote — we will build the MX68 (or MX68W) bill of materials, align the Meraki license co-term, confirm TAA status, and stage the migration so no branch loses protection on the cutover.