Meraki Z3 (Z3-HW) End-of-Life: Migrating to the Z4

The Cisco Meraki Z3 Cloud Managed Teleworker Gateway (PID Z3-HW) was, for years, the default way to extend a corporate network into a home office, a hotel desk, a clinic exam room, or a small remote site. It is a compact, fanless box an end user can plug in with zero on-site IT, while the security team keeps full policy control from the Meraki dashboard. That model still works, but the Z3 has now entered its end-of-life cycle: Cisco announced end-of-sale on September 4, 2024, and the last day of support lands on September 4, 2029. If you still have Z3 units in production, or a drawer of spares, this guide explains exactly what those dates mean for your risk posture and how to move to the functionally equivalent successor, the Meraki Z4 (PID Z4-HW).

Why the Z3 end-of-life matters now, not in 2029

It is tempting to read "last day of support: 2029" as permission to do nothing for years. For a security appliance deployed across dozens or hundreds of uncontrolled remote locations, that is the wrong read. The end-of-sale date already stopped new Z3 purchases through normal channels, so your install base can only shrink as units fail. More importantly, a teleworker gateway is part of your security perimeter: it terminates the AutoVPN tunnel back to a corporate Meraki MX, it carries the home user's traffic under your firewall and content-filtering policy, and it sits in an environment you do not physically control. Once a product passes its support horizon, three things stop that directly affect that perimeter.

• Security firmware ends. After the last day of support, the Z3 stops receiving the firmware updates that carry PSIRT vulnerability fixes. A VPN-terminating edge device with no path to patch a future CVE is exactly the kind of finding auditors flag and attackers hunt for.
• TAC and RMA end. No Cisco TAC case, no advance hardware replacement. When a unit dies in a remote worker's home, your only option is a same-model spare you already own, and those become scarcer every year after end-of-sale.
• Compliance exposure grows. FedRAMP, CMMC, HIPAA, PCI DSS, and most agency ATOs require that perimeter and remote-access devices remain vendor-supported and patchable. Running unsupported gear on a remote-worker path is a documented deficiency you will have to remediate or accept as risk.

For federal, DoD, SLED, and healthcare buyers in particular, the practical deadline is not 2029. It is the date of your next audit cycle or ATO renewal, because an end-of-life device on an accreditation boundary is a finding regardless of how many years of "support" technically remain. Planning the refresh now, while you can stage hardware and stagger shipments, is far cheaper than an emergency swap after a failure or an audit.

What each Z3 milestone date actually means

End of Sale: September 4, 2024

This was the last date Cisco accepted new Z3-HW orders through standard channels. After it, the Z3 is no longer orderable new; the only supply is remaining authorized-partner stock and the secondary market. From this point the support clock starts running toward the fixed end dates below.

End of Software Maintenance: not applicable

Meraki devices do not follow the per-release software lifecycle of a standalone IOS-XE or ASA box, because firmware is delivered centrally from the cloud and there are no separately licensed software trains to retire. In practice the Z3 keeps receiving cloud-pushed firmware until the hardware reaches its last day of support, at which point updates stop. The takeaway: treat September 4, 2029, as both your hardware and your software cutoff.

Last Day of Support (LDoS): September 4, 2029

This is the hard line. After it, Cisco provides no TAC, no RMA, no security firmware, and no bug fixes for the Z3. A unit may keep working, but it does so unsupported and unpatchable. Any Z3 still on a production remote-access path past this date should be treated as accepted risk that must be documented.

The recommended replacement: Meraki Z4 (Z4-HW)

The Z4 is the direct, like-for-like successor to the Z3. It keeps everything that made the Z3 useful, a compact, fanless, dashboard-managed gateway that a non-technical remote worker can self-install, while modernizing the wireless and wired performance that had aged on the Z3. The single most consequential upgrade is the radio: the Z3 shipped 802.11ac Wave 2 (Wi-Fi 5), and the Z4 moves to 802.11ax (Wi-Fi 6).

What concretely gets better

• Wi-Fi 6 instead of Wi-Fi 5. The Z4's 802.11ax dual-band radios add OFDMA and improved MU-MIMO, which is the difference that matters in a real home: a teleworker's laptop, soft phone, two video calls, and a dozen IoT and family devices all share airtime far more efficiently. OFDMA lets the AP service many small frames in a single transmission, cutting latency and jitter on the exact voice and video traffic remote workers depend on.
• Higher effective throughput. With Wi-Fi 6 and 1024-QAM the Z4 delivers meaningfully higher real-world wireless throughput than the Z3's Wave 2 radios, so the gateway stops being the bottleneck on faster home broadband.
• Same self-install model, better client capacity. Like the Z3, the Z4 is a teleworker gateway, not a campus AP, but Wi-Fi 6 raises the number of concurrent clients it handles cleanly before contention degrades the experience. That headroom matters as home device counts keep climbing.
• Modern wired ports with PoE. The Z4 continues the Z3's pattern of multiple gigabit LAN ports plus a dedicated WAN/internet port, and retains a PoE-capable port so a downstream Meraki AP or a PoE desk phone can be powered directly from the gateway, no separate injector at the remote site.
• Identical management and security model. Both run from the same Meraki dashboard with AutoVPN back to your MX, Layer 7 firewall and traffic shaping, content filtering, and group policies. There is no new controller, no NMS, and no learning curve, your existing dashboard org, network templates, and policies carry straight over.

A practical Z3-to-Z4 migration plan

1. Assess and inventory

Pull a full list of Z3 serials from the Meraki dashboard and reconcile it against who actually holds each unit, remote employees, clinic rooms, retail counters, kiosk sites. Capture each device's current network assignment, firmware, license expiry, and the policies bound to it. This inventory is also your audit artifact: it documents which boxes are on a regulated remote-access path and need to be prioritized.

2. Plan the license transition

Order Z4 hardware plus matching Meraki subscription licenses through an authorized partner, and decide your co-termination strategy up front. Because licenses are per-device and do not migrate from Z3, the cleanest approach is to license the Z4 fleet to a common end date that lines up with your broader Meraki renewal or Enterprise Agreement.

3. Confirm config and feature parity

Build a Z4 network template that mirrors your Z3 configuration: SSIDs, VLANs, AutoVPN hub assignment, firewall and traffic-shaping rules, content filtering, and group policies. Because both generations live in the same dashboard, this is largely a copy-forward exercise, but validate the few areas that differ, port count and PoE budget, radio settings that are Wi-Fi 6 specific, and any per-port profiles. Claim the new serials into the dashboard and pre-stage them against the template before anything ships.

4. Handle the physical realities at the remote site

The Z4 keeps the Z3's small, fanless, desk-friendly form factor, so most users can place it exactly where the old unit sat. Check three things per site: that the home or remote broadband handoff still lands on the WAN port as expected, that any device the user was powering off the Z3's PoE port (an AP, a phone) maps to the Z4's PoE port and stays within its power budget, and that the wired LAN devices (printers, desk phones, a workstation) have enough ports. For users who want to take full advantage of Wi-Fi 6, remind them it only helps with Wi-Fi 6 capable client devices, though older clients still connect and benefit from the cleaner airtime.

5. Phased cutover

Do not flash-cut a whole fleet. Pilot with a small group of technical users, confirm AutoVPN comes up, policy applies, and throughput meets expectations, then roll out in waves. Because the Z4 self-installs, the typical pattern is to ship the pre-staged unit to the user, have them plug it in and confirm it appears healthy in the dashboard, then remove the old Z3 from the network. Keep the cutover windows short per user so no one is offline waiting.

6. Secure decommission

Returned Z3 units must be removed from the dashboard org, unassigned from licenses, and factory reset so no residual configuration, keys, or VPN parameters leave with the hardware. For federal and healthcare environments, follow your media-sanitization standard (NIST SP 800-88 style) and document each serial's disposition. Do not resell or e-waste a security appliance without a verified wipe and a recorded chain of custody.

Procurement notes for regulated buyers

• TAA and sourcing. Confirm the Z4 build meets your Trade Agreements Act requirements and request country-of-origin documentation up front for federal and DoD orders.
• Lead times. Because the Z3 is end-of-sale, do not count on emergency spares. Order Z4 hardware on a schedule that lets you stage and ship before your audit or ATO milestone, not after a failure.
• Buy through an authorized partner. Purchasing Z4 hardware and licenses through an authorized Cisco Meraki partner protects warranty, license registration, and TAC eligibility, gray-market gear often arrives with licensing or support gaps that surface at the worst time.
• Contract vehicles. For SLED and federal buyers, align the refresh to your existing purchasing vehicle so the Z4 fleet lands on familiar terms and pricing.

You can review the full lifecycle record for this product on our Z3-HW end-of-life page, browse other affected models on the Cisco end-of-life hub, and check current Meraki teleworker and security hardware on our catalog. When you are ready to size a Z3-to-Z4 refresh with TAA-compliant hardware, co-terminated licensing, and pre-staged dashboard templates, get a quote and our team will build the bill of materials and migration plan around your remote-site footprint.