Direct answer: what the Cisco Meraki MX95 is and when it fits

The Cisco Meraki MX95 is a cloud-managed security and SD-WAN appliance in the MX family. Cisco positions it for medium-to-large branch deployments and environments of up to 500 users. It is mainly used as an Internet edge, branch security gateway and SD-WAN appliance where centralized Meraki Dashboard administration, Auto VPN, application-aware policies, multiple WAN handoff options and license-dependent security services are required.

Organizations should consider the MX95 when a smaller branch appliance would leave too little headroom, when 10 GbE SFP+ interfaces are useful for WAN or LAN connectivity, or when the network design needs a consistent Meraki operating model across several sites. The most important factor to confirm is not simply the number of employees. Sizing must account for real Internet throughput, encrypted VPN traffic, enabled security functions, application mix, concurrent flows, expected growth and resilience requirements.

FourTeck can help determine whether the MX95 is appropriately sized, which license model and feature tier fits the existing Meraki organization, whether a warm-spare pair is required, which SFP/SFP+ optics or copper handoffs are needed, and whether an MX85, MX105 or another platform should be compared before a purchase decision.

Why the MX95 sits in an important part of the Meraki MX range

The MX95 occupies the space between smaller branch security appliances and higher-capacity options intended for larger sites. That position matters because a branch firewall is normally expected to remain in service through multiple Internet circuit upgrades, application changes and periods of user growth. Selecting a model only for today’s average bandwidth can create a costly replacement cycle, while selecting far above the realistic requirement can increase hardware and licensing cost without adding practical value.

Cisco currently describes the MX95 as a medium-to-large-branch appliance for up to 500 users. The product includes four fixed 1 GbE RJ45 LAN ports and two 10 GbE SFP+ LAN ports. On the WAN side, the platform provides two 10 GbE SFP+ interfaces and two 2.5 GbE RJ45 interfaces, with PoE+ capability on one of the RJ45 WAN ports. This interface mix is particularly useful where an ISP presents Ethernet handoff at more than 1 Gb/s, where fibre handoff is required, or where the downstream switching layer benefits from 10 GbE connectivity.

The number of physical WAN connectors should not be confused with the number of simultaneously active WAN uplinks. Meraki documentation describes paired WAN interface behavior on the MX95: each SFP+ interface is associated with an RJ45 partner, and using one member of a pair disables the other member for that pair. Current firmware documentation also describes additional multi-WAN and backup-uplink capabilities, so the intended topology and firmware requirements should be reviewed as part of implementation rather than inferred from the front-panel port count alone.

For a Dubai branch that is moving from 1 Gb/s Internet to a multigigabit service, consolidating several WAN services, or standardizing a multi-site environment on Meraki, the MX95 can therefore be a sensible shortlist candidate. It is not automatically the correct choice for every 500-person office. Security inspection, VPN traffic, application behavior, HA design and future circuit speeds remain more meaningful sizing inputs than employee count by itself.

MX95 specification overview

Performance figures must be read with their test methodology. Cisco product, sizing and datasheet pages can present different values for firewall, VPN and advanced-security workloads because the traffic profiles and measurement definitions differ. Use a design figure that matches the intended production workload rather than mixing metrics from different tests.

How to size the MX95 correctly

A useful MX95 sizing exercise starts with traffic, not headcount. User count is a convenient first filter because it gives a rough idea of session volume, but two offices with the same number of employees can place very different demands on a firewall. A professional-services office may use mostly SaaS, video meetings and cloud storage. A design company may transfer large files to cloud and data-centre resources all day. A retail head office may aggregate store VPN traffic. A healthcare or education deployment may include many more devices than people. Those patterns materially affect firewall, VPN and inspection requirements.

Start by recording the present Internet circuit speed, the expected circuit speed over the planned life of the appliance and the realistic busy-hour utilization. If the site has two ISPs, include both circuits and decide whether they will be used as active uplinks, backup paths or application-specific routes. If an ISP provides 2.5 GbE copper handoff or fibre, confirm the physical interface and transceiver requirement. The MX95 gives useful multigigabit and 10 GbE options, but the surrounding cabling, optics and switch ports must support the same design.

Next, separate ordinary Internet traffic from encrypted site-to-site VPN and remote-access traffic. VPN sizing is especially important for a hub site because traffic from many branches can converge on one appliance. A site that is comfortable as an Internet edge can become constrained if it also acts as a central Auto VPN concentrator for a large estate. Count the number of spokes, estimate aggregate encrypted traffic, note whether traffic is full-tunnel or split-tunnel, and consider the effect of failover scenarios in which traffic may move from one hub or ISP to another.

Security services are another major variable. A firewall forwarding trusted traffic is not the same workload as an appliance applying intrusion prevention, malware inspection, content controls and other security functions to a broad Internet traffic mix. Cisco publishes different test figures for stateful firewall, next-generation firewall and other conditions. A sizing conversation should therefore name the functions that will actually be enabled and use a conservative traffic profile instead of quoting the highest available laboratory number.

Finally, add growth and resilience. A site near the upper end of the model’s realistic workload may be better served by a larger platform if the customer expects faster circuits, more VPN spokes, heavier security inspection or substantial device growth. Conversely, a branch with moderate bandwidth, few users and limited growth may not need the MX95 at all. Good sizing minimizes both technical risk and unnecessary spend.

Performance numbers: why buyers may see different MX95 figures

This distinction is particularly important in the UAE, where enterprise Internet circuits can be upgraded during the life of a firewall. An MX95 selected for a current circuit may have adequate headroom today but still need review if the customer plans significantly faster access, adds multiple branch tunnels, deploys more intensive security inspection or changes the appliance’s role from a branch edge to a regional VPN aggregation point. A sizing worksheet based on production requirements produces a more reliable decision than a single headline throughput value.

WAN interface planning on the MX95

The MX95’s WAN interface design is one of its most distinctive hardware characteristics. It includes two 10 GbE SFP+ WAN connectors and two 2.5 GbE RJ45 WAN connectors. However, these should not be interpreted as four independent active Ethernet uplinks in the simple sense. Meraki documents the SFP+ and RJ45 ports as paired interfaces. If an SFP+ member of a pair is selected, its partnered RJ45 interface is disabled; the inverse applies when the RJ45 member is used. A mixed SFP+/RJ45 arrangement is supported by choosing one active interface from each pair.

This behavior has practical consequences for ISP design. If ISP 1 delivers fibre and ISP 2 delivers copper, the ports must be mapped so each service uses a compatible member of a different pair. If both ISPs deliver copper, both 2.5 GbE RJ45 interfaces can be used. If both deliver fibre, the two SFP+ interfaces can be selected. The Dashboard reports which interfaces are active, while local configuration can be relevant during initial deployment before full cloud connectivity is established.

One RJ45 WAN port supports PoE+. Meraki documents this capability as suitable, for example, for powering a compatible Meraki cellular gateway used as an uplink. That can simplify cabling at sites where an MG gateway provides backup connectivity, although cellular architecture, subscription, coverage, placement and firmware support remain separate design considerations.

Before ordering optics, confirm the service-provider handoff, fibre type, connector, wavelength, distance and required transceiver compatibility. The appliance having an SFP+ cage does not mean every optic or direct-attach cable is appropriate. A quotation should identify whether the buyer needs copper only, specific Meraki transceivers, short-reach or long-reach optics, or existing compatible modules that will be reused.

LAN design and 10 GbE uplink considerations

On the LAN side, the MX95 provides four fixed 1 GbE RJ45 ports and two 10 GbE SFP+ interfaces. This combination suits a typical branch architecture where the firewall connects to one or more access or distribution switches rather than serving as the primary Ethernet access switch for every endpoint. The 1 GbE copper ports can support local connections or smaller downstream segments, while the SFP+ interfaces can provide higher-capacity uplinks into an appropriate switching layer.

The presence of 10 GbE LAN ports can be valuable even when the Internet circuit is below 10 Gb/s. Internal traffic, multiple VLANs and aggregated branch workloads can traverse the firewall, especially when it acts as the default gateway for many segments. A faster uplink reduces the chance that a 1 GbE physical link becomes the immediate bottleneck. It also makes the platform easier to integrate with modern switches that are already using SFP+ uplinks.

That said, a 10 GbE physical link does not imply 10 Gb/s of inspected firewall throughput. Interface speed and security-processing capacity are different. The link can carry at that Ethernet line rate, while the firewall’s actual end-to-end forwarding and security performance depends on the traffic and features in use. This is another reason to separate physical interface planning from appliance performance sizing.

A clean design should document the switch model, uplink medium, VLAN handoff, spanning-tree behavior and resilience requirements. In a high-availability topology, downstream switching becomes even more important because both MX appliances need a reliable Layer 2 relationship for warm-spare operation. If the design uses two switches or a switch stack, cabling and spanning-tree configuration should be planned before the maintenance window rather than improvised during installation.

Meraki Dashboard: the operational model behind the hardware

An MX95 purchase is not only a hardware decision. Cisco Meraki’s operating model is built around cloud-based Dashboard management. Administrators use the Dashboard to configure security and SD-WAN policies, monitor uplinks, view clients, manage firmware, troubleshoot connectivity and maintain consistent configuration across multiple networks. For organizations already using Meraki switches, wireless access points, cameras, sensors or cellular gateways, the common management experience can be a major reason to stay within the platform.

Centralized management changes the branch deployment workflow. The appliance can be added to the Meraki organization and network, configuration can be prepared before the physical installation, and the device retrieves its configuration when it obtains Internet connectivity. This supports a zero-touch or low-touch rollout model where branch technicians follow a defined cabling plan rather than manually building an extensive local firewall configuration.

Cloud management also creates dependencies that should be understood before adoption. The organization must maintain valid licensing, administrator access and appropriate operational processes. Changes should be governed through role-based administration, change control and documented network ownership. If the customer has strict requirements around cloud-managed infrastructure, data location, change approvals or privileged access, those requirements should be reviewed before procurement so the platform aligns with internal policy.

For distributed UAE businesses, the Dashboard model can substantially reduce the need to send senior engineers to every branch for routine changes. A network team can standardize address plans, site-to-site VPN settings, application policies and alerts while retaining local visibility. The operational benefit is strongest when the organization also standardizes naming, templates, administrator roles and support procedures rather than treating each branch as an isolated firewall.

The MX95 therefore makes most sense when the buyer values the Meraki platform itself, not merely a set of ports and throughput figures. A technically similar standalone firewall may have different strengths, but it will not necessarily provide the same deployment and management workflow. Platform fit should be considered alongside hardware fit.

Security capabilities and the importance of the selected license tier

The MX family combines routing, firewalling, SD-WAN and security functions, but the feature set available to the customer depends on licensing. Under traditional co-termination licensing, the common MX tiers are Enterprise, Advanced Security and Secure SD-WAN Plus. Enterprise is aimed at secure connectivity and core SD-WAN requirements. Advanced Security adds the broader unified-threat-management feature set. Secure SD-WAN Plus builds on that with additional analytics and application-experience capabilities.

Cisco has also expanded Subscription Licensing, and the exact subscription SKU structure differs from legacy hardware-specific license part numbers. Subscription licensing is hardware-agnostic by product class and can be managed at the network level. This means an organization planning a new MX95 should not automatically order a legacy LIC-MX95 code simply because it appears in an older quote or bill of materials. The existing Meraki organization’s licensing mode and the desired feature tier need to be checked first.

Meraki does not allow different licensing models to be mixed arbitrarily inside the same organization. Customers already operating co-termination, subscription or restricted legacy per-device licensing should therefore treat the licensing model as an architecture decision, especially during a refresh. Migrating licensing modes may affect procurement, renewal processes and the way networks are associated with entitlements.

Security feature selection should follow the risk and connectivity model. A private branch that primarily needs Auto VPN to a central security stack may have different requirements from a branch that breaks out directly to the Internet and must enforce local intrusion prevention, malware controls and content policies. Likewise, an organization relying on SaaS performance analytics may value Secure SD-WAN Plus features that are unnecessary for a simple branch.

A good quotation therefore names the hardware, licensing model, feature tier and term. It should also state whether the price is for a new entitlement, renewal, upgrade or migration. Treating “MX95 license” as one generic item is not precise enough for enterprise procurement.

Common MX95 legacy license part numbers

These part numbers are useful for identifying established MX95 licensing, but they are not a substitute for checking Cisco’s current regional ordering model. Subscription licensing has changed the way newer Meraki entitlements can be purchased, and a mixed environment requires careful planning. A buyer should provide the Meraki organization name or licensing status, required tier and preferred term when requesting an exact quote.

Licensing procurement warning

Do not assume that an MX95 hardware purchase is complete without an appropriate Meraki license or subscription. The device is part of a cloud-managed platform, and licensing affects both feature availability and administrative compliance. A procurement team should also avoid purchasing a license tier independently of the organization’s existing licensing structure. Cisco documentation states that the supported licensing models are managed at the organization level and cannot simply be mixed inside one organization.

For a new deployment, provide the intended security tier, organization licensing mode, required term and whether the order is new, renewal or expansion. For a refresh, provide the old MX model, existing entitlement details and planned replacement date. This prevents the common situation in which the hardware is available but the license arrangement is not aligned with the organization’s Dashboard configuration.

Meraki Auto VPN and SD-WAN use cases

Meraki Auto VPN is a core reason many organizations select MX appliances for distributed sites. It is designed to simplify encrypted connectivity between Meraki MX networks by using Dashboard-defined topology and policy instead of requiring administrators to build each IPsec relationship manually. For a company with branches in Dubai, Abu Dhabi and other locations, that can make ongoing operations much easier than managing a large collection of individually configured tunnels.

The MX95 can operate as a branch spoke, a larger branch gateway or, in appropriate designs, a VPN concentrator. The correct role changes the sizing calculation. A spoke may primarily encrypt its own local traffic, while a hub can aggregate traffic from many sites. If the MX95 is proposed as a hub, count expected tunnels, aggregate throughput and failover traffic. The fact that the platform supports a high maximum tunnel count in laboratory conditions does not mean a design should operate near that maximum with heavy production traffic.

SD-WAN functionality can also steer or prioritize applications according to uplink conditions and policy. This is useful when a site has two Internet services and needs business-critical traffic to prefer the better-performing path. The organization should identify the applications that matter, their latency and loss sensitivity, and whether the network uses direct Internet access, central breakout or cloud security services. Policies become much easier to design when the application objectives are clear before deployment.

Where non-Meraki peers are involved, standards-based IPsec remains relevant. Remote users can also be served through supported client VPN technologies such as Cisco Secure Client/AnyConnect, subject to current platform capabilities and licensing. These use cases should be included in the capacity plan because encrypted traffic and concurrent remote-user demand can become important during hybrid-work periods or when a site must temporarily carry traffic for another location.

For multi-site organizations, the strongest outcome normally comes from designing the WAN as one system. Address plans, local Internet breakout, VPN topology, SaaS traffic, cloud access, failover behavior and monitoring should be documented together. Buying a firewall for each branch without that common design misses much of the operational value of Meraki SD-WAN.

High availability with an MX95 warm spare

For sites where a single appliance would create unacceptable downtime, Meraki supports MX high availability using a warm-spare pair. The spare must be the same MX model as the primary. Cisco documents the pair using VRRP-based failure detection, and the design can be applied in routed mode or in VPN concentrator deployments depending on the architecture.

A notable procurement point is that Cisco’s traditional warm-spare design requires only one MX license for the HA pair; the warm-spare unit does not require a separate device license under that model. Licensing terms should still be verified against the customer’s current licensing program, especially as Cisco expands subscription-based licensing. Hardware quantity, however, is two appliances, and both units need suitable WAN and LAN connectivity.

HA cabling must be designed carefully. In routed high availability, both MX devices need reliable LAN communication so VRRP heartbeats are seen consistently. Meraki recommends using downstream switching rather than directly connecting the two appliances as if they were a simple point-to-point pair. Fully redundant designs may use two switches or a switch stack, with spanning tree enabled and cabling arranged so a single switch failure does not isolate one appliance.

WAN addressing is another prerequisite. Both appliances require their own uplink addresses for Dashboard connectivity. If virtual IP addressing is used, the virtual address must be in the same subnet as the appliance uplink addresses and must be unique. This can affect ISP handoffs that provide only one usable public IP address, so the public addressing plan should be confirmed before installation.

An HA quote should therefore include the second MX95, any additional optics or cables, downstream switching implications, public-IP requirements and an implementation plan. High availability is not achieved simply by placing a second boxed appliance in the rack; the network topology, addressing and operational test plan are equally important.

Physical installation requirements in Dubai and the UAE

The MX95 is a 1U rack-mount appliance with an internal power supply. A basic installation therefore requires a suitable 19-inch rack position, stable AC power, appropriate patching and enough clearance for airflow. The published operating-temperature range is 0 °C to 40 °C. In UAE environments, this makes reliable room cooling important; a communications cabinet located in an unconditioned storeroom or near a heat source can create avoidable reliability risk.

Rack planning should include cable management and port access. SFP+ fibre or DAC connections need bend-radius awareness and should not be pressed against a cabinet door. If copper WAN services are presented through an ISP router or ONT, confirm the handoff speed and duplex. For 2.5 GbE copper, the upstream equipment, cabling and negotiated link must all support multigigabit Ethernet; otherwise the link may fall back to a lower rate.

Power protection should match the importance of the site. A small branch may use a single UPS to cover the firewall, ISP CPE and core switch. A high-availability site should assess whether the two MX units and their downstream switches can be placed on separate UPS feeds or power circuits. Redundant firewalls connected to one unprotected power strip do not provide meaningful resilience against a power event.

The installation plan should also identify how the appliance obtains initial Dashboard connectivity. If the Internet circuit requires a static IP, VLAN tag, PPPoE or special ISP parameters, those settings may need to be staged through the local status page. Administrative credentials and change approvals should be prepared in advance so the engineer does not spend the maintenance window waiting for access.

For office moves or new branches, coordinate the MX95 deployment with ISP activation, switch configuration, wireless rollout, DHCP/DNS services and application testing. The security appliance is only one part of the branch launch, and most delays come from dependencies around it rather than from physically mounting the unit.

Migration from an existing firewall to MX95

A firewall migration should be treated as a configuration and dependency project rather than a hardware swap. Before replacing the existing edge device, export or document the current WAN settings, VLAN interfaces, DHCP scopes, static routes, NAT rules, inbound publishing, site-to-site VPNs, remote-access configuration, DNS behavior, security policies and any special application exceptions. If the existing firewall has been in service for years, configuration often contains legacy rules whose owners are no longer obvious. Migration is a good time to validate those rules rather than copying them blindly.

Addressing is usually the first technical dependency. If the MX95 will become the default gateway for existing VLANs, each interface or VLAN IP must be recreated correctly and the downstream switch must be prepared for the same or revised trunk configuration. If the current firewall and MX95 will coexist temporarily, duplicate addressing must be avoided. Static routes to internal routers, VPN concentrators or data-centre networks should be mapped carefully.

NAT and inbound services deserve dedicated testing. Publicly exposed applications, IP phones, VPN servers, mail relays, building systems or remote-management portals may depend on port forwarding or one-to-one NAT. If the ISP assigns new public IP addresses during the migration, DNS records and third-party allowlists may need coordinated changes. Cloud services sometimes trust a customer’s source public IP, so outbound changes can be as important as inbound rules.

VPN migration should include every peer and routing domain. Meraki-to-Meraki Auto VPN is straightforward once sites are part of the same design, but third-party IPsec peers can have specific encryption proposals, lifetimes, selectors and routing expectations. Verify those before the cutover. Remote users should receive the correct client configuration and authentication method, with a fallback support process in case access fails after the edge change.

A good cutover plan includes pre-staging, a maintenance window, a written test list and a rollback threshold. Test Internet access, DNS, SaaS applications, critical internal systems, each VPN class, inbound services, voice, guest networks and monitoring. If the migration affects several branches, start with a representative pilot site rather than changing every office on the same evening.

The MX95’s cloud-management model makes repeat deployments easier after the first site is validated. Templates, standardized policies and documentation can then reduce risk for the remaining branches. The first migration should therefore be designed as the reference implementation for the wider rollout.

Logging, monitoring and troubleshooting approach

Operational visibility is one of the practical benefits of the Meraki platform. Dashboard provides centralized views of appliance status, uplinks, clients and network events, allowing administrators to investigate branch issues without relying exclusively on command-line access to the firewall. For a distributed organization, that can shorten the time between a user complaint and an informed diagnosis.

The monitoring plan should go beyond merely checking whether the MX95 is online. Configure appropriate alerts for uplink changes, warm-spare events, VPN status and other business-relevant conditions. Identify who receives those alerts, what constitutes an incident and when the ISP or internal network team should be engaged. An alert that goes to an unmonitored mailbox adds little operational value.

Traffic and application visibility can help distinguish Internet circuit problems from LAN, DNS, SaaS or server-side issues. When an application is slow, check loss, latency, path changes, uplink utilization and client-specific behavior before assuming the firewall is saturated. If a customer subscribes to higher-tier analytics features, those capabilities should be incorporated into the support process rather than purchased and ignored.

Remote troubleshooting should also include access to the ISP edge and downstream switching where possible. A firewall can report that its WAN link is down, but restoring service may still require information from the carrier router, optical handoff or building cabling. Likewise, an MX LAN interface can be healthy while a downstream switch loop or VLAN error prevents users from reaching applications.

For managed environments, establish a baseline after deployment: normal uplink utilization, expected VPN paths, typical application behavior, firmware version and site inventory. That baseline makes later changes easier to evaluate and gives support engineers a reference when the customer reports that “the network is slower than before.”

Firmware and change-management considerations

Meraki appliances are designed around centrally managed firmware, but firmware still deserves structured change control. New releases can add functionality, change behavior or resolve security and stability issues. A business should know who approves firmware changes, whether critical sites have special maintenance windows and how upgrades are coordinated across branches.

For MX95 specifically, some WAN and PoE behavior is tied to firmware capabilities documented by Cisco. Multi-WAN backup options and local control of the PoE-enabled WAN port are examples of features that have evolved over the MX firmware lifecycle. If a proposed design depends on a particular capability, confirm that the organization can run a firmware release that supports it and that other Meraki devices in the network are compatible with the planned version.

High-availability sites need additional care during upgrade planning because failover behavior becomes part of the maintenance sequence. The purpose of HA is to reduce service interruption, but it should not be treated as permission to upgrade without validation. Monitor the pair before and after changes, verify VPN and uplink state, and confirm that both appliances return to the expected roles.

A simple operational policy is useful: maintain a supported firmware train, review release notes for relevant features and known issues, test significant changes on a representative site when possible, schedule upgrades during agreed windows, and record the result. This keeps cloud-managed networking disciplined without adding unnecessary bureaucracy.

MX95 fit by deployment scenario

When the MX95 may be too small

A larger model should be evaluated when the site’s projected traffic is close to the practical performance envelope after security services are enabled, when the office expects much higher circuit speeds, when VPN aggregation demand is substantial, or when the device count and session profile are likely to grow beyond the MX95’s intended branch role. The MX105 is the nearest traditional MX step up and is positioned for larger branch requirements, while Cisco’s newer secure-router options address significantly higher-capacity use cases.

The key is to identify what creates the pressure. If the constraint is Internet firewall throughput, use that metric. If the constraint is encrypted VPN traffic, focus on the VPN workload. If it is the number of tunnels, consider both tunnel scale and aggregate traffic. If the issue is interface density, a larger firewall may not be the only solution; the switching architecture may need adjustment instead.

Another reason to move up a model is lifecycle headroom. A company planning a 1 Gb/s circuit today may sign a 3 or 5-year firewall agreement while expecting 2 or 5 Gb/s connectivity later. Buying directly at the limit can cause a premature refresh. On the other hand, buying an oversized platform solely because “10 GbE sounds safer” can waste budget if the traffic and services will remain modest.

The sizing recommendation should therefore include both current and planned-state assumptions. If the buyer provides circuit roadmap, security tier, user/device growth and VPN topology, the model comparison can be based on evidence rather than guesswork.

When a smaller MX may be enough

The MX95 should not be selected automatically for every office that wants Meraki security. An MX85 or another smaller platform may be sufficient where the branch has lower bandwidth, fewer users and devices, modest VPN demand and no need for the MX95’s higher-speed WAN/LAN interface mix. The smaller option can reduce both hardware and license cost while still preserving the same overall Dashboard operating model.

A lower-capacity model is especially worth comparing for satellite offices, retail locations and small branches that connect primarily to cloud services over sub-gigabit Internet circuits. If those sites use the same policies as the larger headquarters, Meraki can still provide a standardized management experience without forcing identical hardware into every location.

The best multi-site architecture is often tiered. A larger MX95 or MX105 can serve the primary branch or aggregation point, while smaller locations use appropriately sized appliances. Standardization should mean consistent design and management, not necessarily one hardware model everywhere.

Compare models using the same workload assumptions: security services, WAN speed, VPN requirements, device count, interfaces, resilience and growth. If the smaller platform still has comfortable headroom, it may be the better commercial decision.

Accessories and items that may need to be quoted separately

What information improves an MX95 quotation

A quote can be produced from a model name alone, but a useful quote requires more context. Start with quantity and deployment location. Then specify whether each appliance is a standalone branch gateway, a warm-spare pair, a VPN hub or part of a wider SD-WAN refresh. Hardware quantity can change quickly once resilience requirements are included.

Provide the current and planned Internet circuit speeds and the physical handoff from each carrier. If the handoff is fibre, include the optic or connector information. If the WAN will use 2.5 GbE copper, identify the ISP equipment and cabling. If a cellular gateway is required, include the carrier strategy and whether the gateway needs to be powered from the MX95 PoE-capable WAN port.

Licensing details are equally important. State whether the customer already has a Meraki organization, which licensing model it uses, the desired security or SD-WAN feature tier, and the required term. If the buyer is refreshing an existing MX, provide the current hardware and license expiration information so renewal and migration can be considered together.

For sizing, share the approximate user and device count, peak Internet usage, number of VPN sites, expected encrypted traffic and any heavy applications. If the branch hosts services, note inbound NAT and public-IP requirements. If the customer has regulatory or operational policies around cloud management, log retention or administrator access, include them before design sign-off.

For migration services, provide the existing firewall brand and model, current configuration export if available, maintenance-window constraints and testing priorities. These inputs allow the quotation to separate hardware, licensing, accessories and implementation work clearly instead of hiding assumptions inside a single price.

UAE availability and sourcing guidance

Cisco Meraki hardware and licensing are channel products, so availability, lead time and entitlement details should be confirmed against the exact order requirement. UAE buyers should identify the hardware SKU MX95-HW, required quantity, license or subscription arrangement and accessories before requesting final commercial confirmation. The most common delays occur when the hardware is specified but the license tier, term or optic requirement is still undecided.

For broader UAE procurement and infrastructure enquiries, visit FourTeck UAE. For international and multi-country technology requirements, FourTeck provides a wider company reference point. Firewall-focused projects in Dubai can also be coordinated through Firewall Dubai by FourTeck.

Where the MX95 deployment is part of a larger support, migration or managed-infrastructure engagement, FourTeck IT Services UAE is relevant for the service layer around the appliance. The final scope should state whether the buyer needs supply only, staging, on-site installation, migration, high-availability implementation, VPN rollout, documentation or ongoing support.

Security-policy design before deployment

A new MX95 should not inherit a flat “allow everything outbound” design simply because the old firewall used one. Before deployment, map business networks and trust zones: corporate users, servers, voice, guest Wi-Fi, IoT, building management, CCTV, development systems and any partner or contractor segments. Decide which groups need to communicate and which should remain isolated. The resulting policy should be understandable enough that future administrators can maintain it without guessing the original intent.

Layer 7 controls and content policies can be useful, but they should support a defined business objective. Blocking broad categories without an exception process can create unnecessary support tickets. Conversely, leaving high-risk traffic unrestricted because “the firewall is installed” gives a false sense of security. License tier and security settings should be selected as part of one policy discussion.

Intrusion prevention and malware-related controls also affect performance sizing. If the site needs a strong security posture on all direct Internet traffic, use the relevant security throughput assumptions when choosing the appliance. If the branch sends traffic to a separate cloud-security service, understand which inspection is performed locally and which is performed upstream. Duplicating controls can add complexity without necessarily improving outcomes.

Document exceptions. Some applications need unusual ports, source-IP allowlisting or long-lived sessions. Those requirements should be recorded with an owner and business reason so they can be revisited later. A clean MX95 deployment is easier to operate when policy decisions are visible rather than buried in a list of unexplained rules.

Finally, include administrator security. Use appropriate Meraki organization roles, strong authentication and a controlled support-access process. The firewall protects the network edge, but the management plane also needs deliberate governance.

Application performance and QoS considerations

Modern branches are often limited by application experience rather than raw bandwidth. Voice, video meetings, virtual desktops and interactive SaaS can become unusable with packet loss or latency even when the WAN circuit is not fully saturated. The MX95’s SD-WAN and traffic-management capabilities are most valuable when the network team defines which applications are business-critical and how they should behave during congestion or uplink degradation.

Start by identifying real-time applications and their endpoints. Voice and conferencing generally need stable latency, low loss and predictable queues. Large backups and software downloads are less sensitive to delay but can consume a significant share of the circuit. Policy should prevent bulk traffic from crowding out interactive services without creating a complex rule set that no one can maintain.

With dual WAN links, application-aware path selection can improve resilience. A secondary ISP should not be considered equivalent merely because its advertised speed is similar. It may have different latency, peering, loss or routing to key SaaS providers. Baseline both links and decide what traffic is allowed to move during degradation. If the backup circuit is much smaller, the failover policy may need stronger traffic shaping than the normal state.

Higher Meraki license tiers can provide additional analytics and SaaS quality-of-experience capabilities. Those tools are most useful when linked to support workflows: define what constitutes poor performance, who investigates the issue, and whether the problem belongs to the LAN, ISP, cloud provider or application team.

Performance management is therefore an operational discipline, not just a checkbox in the license. The MX95 provides a platform for that discipline, but the business still needs priorities, baselines and ownership.

Procurement risks to avoid

• Buying hardware without aligned licensing. The MX95 belongs to the Meraki cloud-managed platform. Confirm entitlement model, tier and term before issuing the purchase order.
• Using the highest published throughput figure as the design number. Different Cisco documents use different traffic profiles and test methods. Size for the actual security and VPN workload.
• Assuming all four WAN connectors are independent active uplinks. Paired SFP+/RJ45 behavior affects how services are connected. Map the ISP handoffs to the correct interface pairs.
• Forgetting optics and cabling. Fibre services and 10 GbE switch links may need compatible SFP+ modules or DACs that are separate from the appliance.
• Treating HA as a second box only. Warm-spare deployments require compatible switching, WAN addressing, power design and a tested failover topology.
• Ignoring the migration workload. NAT, VLANs, VPNs, public IPs and application dependencies need a structured cutover plan.
• Sizing only for employee count. Device density, SaaS use, encrypted traffic, inspection services and growth are usually more useful indicators of load.

Planning an MX95 deployment as part of a wider Meraki network

The MX95 becomes more valuable when it is designed with the rest of the branch rather than treated as an isolated edge appliance. In a Meraki environment, switches, wireless access points, cellular gateways and security appliances can be administered through the same broader cloud platform. That does not remove the need for network architecture, but it can simplify visibility and operations when naming, templates and responsibilities are standardized.

Start with the physical topology. Decide which switches connect to the MX95, which links carry VLAN trunks, whether there is a switch stack, and whether the firewall pair needs redundant paths. Then define Layer 3 ownership: which VLAN gateways live on the MX, whether the switching layer performs any routing, and how traffic reaches data centres, cloud services and partner networks.

Wireless and guest networks should be included early. Guest Internet access may require local breakout, client isolation and bandwidth controls. Corporate wireless may need access to internal services over Auto VPN. Voice devices may require dedicated QoS. IoT and camera networks may generate steady upstream traffic that changes the WAN baseline. Each of these networks contributes to the firewall workload even though the users may not think of them as “Internet traffic.”

If an MG cellular gateway is used, determine where it sits physically and logically. Cellular reception may be poor inside a rack or interior server room, so the gateway may need a better location while still connecting back to the MX95. The PoE-capable WAN port can simplify power for supported devices, but coverage and carrier performance remain independent variables.

Finally, document the site as a complete service: circuits, MX95, switches, wireless, addressing, VPN, monitoring, power and support contacts. The result is easier to troubleshoot and much easier to reproduce across additional UAE branches.

Support and lifecycle considerations

Enterprise firewall purchases should be evaluated over the expected operating life, not only at installation. Confirm that the MX95 is appropriate for the planned bandwidth roadmap, that licensing renewals are understood and that the organization has an owner for Dashboard administration. A device can be technically suitable on day one yet become operationally difficult if licensing and account ownership are poorly documented.

Keep serial numbers, order references, license or subscription details and network ownership in an asset register. In a multi-site environment, record which physical MX belongs to which Dashboard network and which site. This becomes particularly important during hardware replacement, office relocation or incident response.

Support planning should define the boundary between the Internet provider, internal IT, Meraki support and any managed-service partner. When a branch is down, the fastest resolution comes from knowing who owns the circuit, who can access the Dashboard, who can visit the site and who can authorize configuration changes. A technically advanced firewall cannot compensate for unclear support ownership.

Review capacity periodically. Circuit upgrades, new cloud applications, acquisitions and additional VPN sites can change the workload without changing the original number of office staff. Use Dashboard observations and WAN utilization to compare actual demand with the assumptions used during procurement.

Finally, follow Cisco lifecycle notices and supported firmware guidance. When a future replacement is planned, treat it as an opportunity to reassess the architecture rather than simply replacing the MX95 with the next model in the same position. Network requirements may have changed substantially by then.

Buyer decision recap

What FourTeck needs from the buyer for an accurate MX95 quote

Frequently asked buyer questions about Cisco Meraki MX95

Plan the MX95 around your real branch workload

The Cisco Meraki MX95 is a strong candidate for a medium-to-large branch that needs cloud-managed security, SD-WAN, multigigabit WAN options and 10 GbE uplinks. The purchasing decision becomes much more reliable when the quote also captures licensing, VPN topology, security inspection, high availability, optics, migration scope and future Internet bandwidth.

Share the site count, circuit speeds, user/device estimate, current firewall, Meraki licensing status and required resilience. That information is enough to determine whether MX95 is the right fit or whether a smaller or larger alternative should be evaluated.